BUG: Problems with new scipy 1.13 RegularGridInterpolator spline interpolation beyond documented behaviour about scipy HOT 4 CLOSED

Hi @ev-br , thanks a lot for the quick response. Indeed, I can confirm that the error occurs for (and only for, as far as I see) a dataset with NaNs (and previously, instantiation was possible even with NaNs being present). I will investigate further if I still see a discrepancy in performance for a dataset without NaNs, using the _legacy methods. However, if _legacy methods should be identical to before also if NaNs are present, I can already tell that it does not seem to be the case for me, and I will see if I can create a minimal data set to reproduce it.

from scipy.

1. the error indicates that values have infs or nans. This is indeed a problem, and the fact that it worked previously is an accident, really.

2. _legacy methods should be exactly identical to what it was in the previous scipy releases. If they are not, it's a bug. Would you please be able to add a minimal reproducible example for us to take a look?

from scipy.

Dear @ev-br , I investigated further and contrarily to what I previously claimed, I see no difference between the _legacy methods in scipy 1.13 and the corresponding methods in scipy < 1.13. So everything seems to work as expected and this issue can be closed I guess. However, let me allow to ask two questions:

• As the new spline RegularGridInterpolator instantiation may take significantly more time than before for the benefit of faster interpolation afterwards, aren't there case where a different trade-off is desired, i.e., fast instantiation is more important? So to permanently allow to choose the most suitable method in the future?
• Shouldn't it be possible (at one's own risk) to allow interpolation on a grid containing NaNs?

Thanks a lot again for your support!

from scipy.

Thanks for confirming the _legacy behavior!

aren't there case where a different trade-off is desired, i.e., fast instantiation is more important? So to permanently allow to choose the most suitable method in the future?

Sure. Only a user can decide what's most suitable for their specific problem though. The best a library can do is to offer a choice, here between cubic or cubic_legacy etc.

Shouldn't it be possible (at one's own risk) to allow interpolation on a grid containing NaNs?

Sure.
Just keep ising linear, nearest and _legacy methods :-).

Alternatively, you can provide your own solver argument. It should look like sparse.linalg.solve or iterative solvers from sparse.linalg, that's the only requirement. See https://github.com/scipy/scipy/blob/main/scipy/interpolate/_ndbspline.py#L355
I'm sceptical TBH --- the 'missing value' nan semantics is inherently at odds with the 'not-a-number' semantics that scipy.linalg and scipy.interpolate adhere to. But don't let my skepticism discourage you, I'd be happy to be proven wrong. So if you manage to make it work, do let us know!

from scipy.