You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SO answer has a prototype implementation and a link to the math description. Basically, the design matrix needs a small tweak to account for the targer values at x[0] and x[-1].
Describe the solution you'd like.
Thinking out loud about the UI: The first thought is it should probably mirror that of make_interp_spline:
>>> l, r = [(0, y0)], [(0, y1)]
make_lsq_spline(x, y, bc_type=(l,r))
would fix the "zeroth derivative" (i.e., the function value) at x[0] to be y0 and the value at x[-1] to be y1. Higher derivatives should raise NotImplemented until, well, implemented.
This is a somewhat awkward, as it's designed for make_interp_spline which needs way more flexibility.
We can instead opt for something simpler, like bc_type=(y0, y1). If/when there's a request for higher derivatives, we'll need to be able to tell a single value y0 (which can be an array if y.ndim > 1) from a sequence of pairs (order, value). Which is not nice.
So probably the pragmatic thing is to add a separate keyword, clamp_values=(y0, y1) or some such.
Describe alternatives you've considered.
The SO question has an implementation in the userspace. It has several issues: 1) it uses full matrices (could use banded linalg), 2) it constructs and solves the normal equations to solve the LSQ problem (should preferably use QR or SVD), and 3) getting the spline basis is a little awkward.
None of these is a blocker, so all in all this is medium-prio enhancement request.
Additional context (e.g. screenshots, GIFs)
No response
The text was updated successfully, but these errors were encountered:
Doesn't the knots satisfying the Schoenberg Whitney conditions in make_lsq_spline take care of the boundary conditions ? So a separate bc_type is not needed perhaps?
Is your feature request related to a problem? Please describe.
Add an option to specify boundary conditions to
make_lsq_spline
. A first useful step would be to allow specifying the values at the boundaries, see https://stackoverflow.com/questions/78482220/fixing-boundary-values-on-a-spline.The SO answer has a prototype implementation and a link to the math description. Basically, the design matrix needs a small tweak to account for the targer values at
x[0]
andx[-1]
.Describe the solution you'd like.
Thinking out loud about the UI: The first thought is it should probably mirror that of
make_interp_spline
:would fix the "zeroth derivative" (i.e., the function value) at
x[0]
to bey0
and the value atx[-1]
to bey1
. Higher derivatives should raise NotImplemented until, well, implemented.This is a somewhat awkward, as it's designed for
make_interp_spline
which needs way more flexibility.We can instead opt for something simpler, like
bc_type=(y0, y1)
. If/when there's a request for higher derivatives, we'll need to be able to tell a single valuey0
(which can be an array if y.ndim > 1) from a sequence of pairs(order, value)
. Which is not nice.So probably the pragmatic thing is to add a separate keyword,
clamp_values=(y0, y1)
or some such.Describe alternatives you've considered.
The SO question has an implementation in the userspace. It has several issues: 1) it uses full matrices (could use banded linalg), 2) it constructs and solves the normal equations to solve the LSQ problem (should preferably use QR or SVD), and 3) getting the spline basis is a little awkward.
None of these is a blocker, so all in all this is medium-prio enhancement request.
Additional context (e.g. screenshots, GIFs)
No response
The text was updated successfully, but these errors were encountered: