Hi,
TL;DR: Here’s a proposal to declare as legacy
several FITPACK-wrapping 1D interpolators in scipy.interpolate: *UnivariateSpline
classes and the functional interface, splrep
and splprep
.
Historically, much of scipy.interpolate relies on wrappers of the Fortran 77 FITPACK library by P. Dierckx. Also for historical reasons, we ship two sets of wrappers: class-based *UnivariateSpline
interface and functional interface of splrep
and splprep
functions (the former is for 1D data and the latter is for parametric curves).
Starting today, we have a third implementation, make_splrep
and make_splprep
, merged in ENH: interpolate: replicate `splrep` and `splprep` in Python by ev-br · Pull Request #19970 · scipy/scipy · GitHub
These new functions implement the same algorithms and heuristics as FITPACK, and use a more modern user API: they receive data arrays and return BSpline instances—this is consistent with make_{interp,lsq,smoothing}_spline
functions.
Note that these new functions are not a complete FITPACK replacement:
- in 1D,
splrep
andsplprep
implement periodic splines, and thesemake_*
functions do not (yet) - FITPACK has 2D spline fitting for both gridded and scattered data
So here’s a proposal to declare the venerable implementations as legacy. To recap, the legacy status roughly means “please don’t use in new code, use better alternatives instead”; it is only visible in the documentation, legacy functions keep working as before, and do not emit any warnings.
Possible alternatives:
-
deprecate the FITPACK wrappers.
This is premature I believe. We should at least first have some user experience with these
new implementations. And the deprecation will be very painful, so it’s more of a SciPy 2.0
event if we ever go for it. -
reimplement
UnivariateSpline
and functional FITPACK interface with these new functions.
This potentially has rather nasty backwards concerns. The algorithmic content of “new” and
“old” implementations is the same, but we do not guarantee bit-for-bit identical results (and
I don’t believe we can guarantee that). So this would mean that users silently get different
results. Which is not good. -
wait until we have a full replacement, for both 1D and 2D splines.
While this is of course an option, I think we can start gently nudging users towards using the
new interface. There are a lot of recommendations out there which basically says “use
UnivariateSpline”, and it’ll take a while to get the message across about the new stuff. -
do nothing; keep shipping three user-visible sets of APIs.
Also an option, same concern.
Thoughts?
Cheers,
Evgeni