ascending order in interpolation routines (Trac #1764)

[scipy-gitbot]

Original ticket http://projects.scipy.org/scipy/ticket/1764 on 2012-11-03 by trac user theyoud, assigned to @pv.

Interpolation (and spline) functions, such as interpolation.interp1d, currently require the array of independent variables (x values) be given in ascending order. These functions could be enhanced to also accept descending order. Such a modification would avoid unnecessary reversing of arrays. Also it would make the routines harder to break.

Currently if an array in descending order is specified for x, the behavior is problematic. The interpolation function is created without error, but when you try to evaluate the interpolation function (at an x value that is in range) you get an error message that the x value is out of range.

The following code illustrates the problem I describe above:

import numpy as np
from scipy.interpolate import interp1d

xa = np.arange(10)[::-1]
ya = xa**2
f = interp1d(xa , ya)
f(5.5)

While the interpolation fn. f is created, there is an error on the attempted evaluation.

ValueError: A value in x_new is below the interpolation range.

It's probably a "bug" to create a non-functioning interpolation fn. The better "enhancement" is probably to accept both ascending and descending order.

[scipy-gitbot]

@rgommers wrote on 2012-11-04

Agreed, interpolation routines could be more robust. Also catching duplicate values would be useful. Patches very welcome. Note that interp1d/interp2d are a bit outdated, the class-based interfaces (UnivariateSpline/BivariateSpline) are better and should be further improved.

[djarecka]

Is it ok to just add some sorting methods to the interp1d(x, y)? If yes, I can try to change it.

[pv]

The simplest fix is probably to add a new keyword argument assume_sorted=False and do the sorting if not assume_sorted --- in case someone finds sorting is too expensive. The default would be to sort.