Declare `*UnivariateSpline` classes and `splrep`, `splprep` functions legacy

Contributor & Development Discussion scipy
1

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 and splprep implement periodic splines, and these make_* 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

1 Like
2

Agreed with all of the remarks here. For “wait until we have a full replacement”, do you have a sense of how long that may take?

3

For “wait until we have a full replacement”, do you have a sense of how long that may take?

There’s no ETA at the moment, no.
The effort is relatively significant, if finite. So if somebody wants to join the effort, that’d be great :-).

4

Given that there are no objections for nearly two months, here’s a DOC-only PR to declare 1D FITPACK wrappers legacy: