Skip to content

Faster de Boor #1

merged 1 commit into from Feb 7, 2012

2 participants

alang9 commented Feb 6, 2012

I noticed that your implementation of de Boor seemed to be quadratic in the number of control points rather than in the degree. This version is quadratic in the number of degrees instead, but it can still probably be made much faster.

Note also that this produces "natural" b-splines, which take the value 0 before and after the first and last knot resp. (I happen to prefer this, but it might not be what you want for your library).


@alang9 alang9 Faster version of deBoor. It assumes that the splines are `natural', …
…i.e. they take the value 0 before and after the last spline.
mokus0 commented Feb 7, 2012

Thank you! I had intended to do this but never got around to it. The existing implementation is indeed quadratic in the number of control points. As I recall, laziness makes the cost proportional to (number of control points * number of knots less than x + degree^2), so not only is it worse than it should be, it's not even uniform across the spline.

I don't have a strong opinion about the behavior at the ends, but I do find the "natural" evaluation strategy inconvenient for clamped splines - they approach the last control point but then suddenly snap to zero when they reach it. I understand that it is mathematically elegant in some ways, but from a practical standpoint it really seems ugly to have to treat the last control point specially to avoid a bizarre (to the user) discontinuity.

My current inclination is to have 'evalBSpline' continue to have the same meaning it does now (so code that depends on the current behavior doesn't break) and add a new function 'evalNaturalBSpline'. That's a fairly long name though, so I'm open to other suggestions if you prefer something shorter.

@mokus0 mokus0 merged commit b86755d into mokus0:master Feb 7, 2012
mokus0 commented Feb 7, 2012

I've restructured the code a bit - the old 'deBoor' output is used by the code to split b-splines, so I've separated your changes into a new function 'slice' that extracts the needed part of the spline before passing it to 'deBoor'. You may wish to proof-read the changes - my ad-hoc quickCheck tests indicate it behaves identically for all inputs it generated, but it's always possible that it missed some corner cases.

alang9 commented Feb 11, 2012

Hi mokus0,

The changes look great to me, I won't have time to test them for another few days, but I'll tell you if I find anything.

Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.