spapi: why slvblk instead of backslash operator?

% data
x = [3.0,4.5,6.0,7.5,9.0,12.0,15.0];
y = [0 0.0343653 0.0694232 0.105143 0.141178 0.246013 0.630537];
xq = linspace(min(x), max(x), 1000);
[f, fd, fdd] = Evaluate_spline(xq, x, y, order);
% plotting (xq,f), ... gives the same curves as produced by spapi

function [yq, fd, fdd] = Evaluate_spline(xq, x, y, order)
    
    t = aptknt(x, order);
    A = spcol(t, order, x);
    sol = A\y(:);

    yq = 0;
    fd = 0;
    fdd = 0;
    for i=1:numel(x)
        spline = spmak(t(i:i+order), 1);
        yq = yq + fnval(spline, xq) .* sol(i);
        fd = fd + fnval(fnder(spline, 1), xq) .* sol(i);
        fdd = fdd + fnval(fnder(spline, 2), xq) .* sol(i);
    end
    
end

However, in my code, I simply used "\" operator to solve the linear system for the control points whereas spapi is calling slvblk.

(1) Is that for reasons of efficiency when the number of data points becomes larger? Or are there other reasons and using backslash is not appropriate (inaccurate, unstable, ...) for some cases.

The reason to implement an own version is that I have to evaluate the spline at a large number of points which I know one-by-one at runtime. If I am not mistaken, calling fnval(spline, x) uses the De Boor's algorithm (recursion). Are there better ways for frequent evaluations of a spline?

Thank you!

Answer 1

[Shivansh]

Hi SA-W,

The backslash operator (\) for solving linear systems in spline approximation tasks, as in your custom "Evaluate_spline" function, is generally appropriate for small-sized problems. It automatically selects an efficient and suitable solution method. However, for larger datasets or specific structures like block-diagonal matrices common in spline computations, specialized functions such as "slvblk" can offer better performance and stability. The "slvblk" function is optimized to exploit the block-diagonal structure, which might make it more efficient and potentially more numerically stable for these cases.

If you're dealing with a large number of points one-by-one at runtime, the direct use of "fnval" and De Boor's algorithm can be an efficient approach due to its recursive nature. If performance becomes a concern, consider strategies like pre-computing constant parts, vectorizing evaluations and leveraging MATLAB's optimized handling of vector and matrix operations, or implementing critical sections in a compiled language via MATLAB's "mex" interface for maximum performance.

You can refer to the following documentation to learn more about "mex": https://www.mathworks.com/help/matlab/ref/mex.html.

I hope it helps!