# spapi: why slvblk instead of backslash operator?

4 views (last 30 days)
SA-W on 7 Mar 2024
Edited: SA-W on 10 Apr 2024
% 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!

Shivansh on 20 Mar 2024
Edited: Shivansh on 20 Mar 2024
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.
I hope it helps!