On 2013/06/04 4:15 PM, Benjamin Root wrote: > Could non-monotonicity be detected as part of the interp process? > Perhaps a sign switch in the deltas?
There are two code paths, depending on the number of points to be interpolated. When it is greater than the size of the table, the deltas are pre-computed in a single sweep. Non-monotonicity could be detected there at moderate cost. In the other code path, for a smaller number of points, the deltas are computed only as needed, so monotonicity testing would require a separate sweep through the points. That's the costly case that I think might reasonably be an option but that should not be required. Eric > > I have been bitten by this problem too. > > Cheers! > Ben Root > > On Jun 4, 2013 9:08 PM, "Eric Firing" <efir...@hawaii.edu > <mailto:efir...@hawaii.edu>> wrote: > > > > On 2013/06/04 2:05 PM, Charles R Harris wrote: > > > > > > > > > On Tue, Jun 4, 2013 at 12:07 PM, Slavin, Jonathan > > > <jsla...@cfa.harvard.edu <mailto:jsla...@cfa.harvard.edu> > <mailto:jsla...@cfa.harvard.edu <mailto:jsla...@cfa.harvard.edu>>> wrote: > > > > > > Hi, > > > > > > I would like to suggest that the behavior of numpy.interp be > changed > > > regarding treatment of situations in which the x-coordinates > are not > > > monotonically increasing. Specifically, it seems to me that interp > > > should work correctly when the x-coordinate is decreasing > > > monotonically. Clearly it cannot work if the x-coordinate is not > > > monotonic, but in that case it should raise an exception. > Currently > > > if x is not increasing it simply silently fails, providing > incorrect > > > values. This fix could be as simple as a monotonicity test and > > > inversion if necessary (plus a raise statement for > non-monotonic cases). > > > > > > > > > Seems reasonable, although it might add a bit of execution time. > > > > The monotonicity test should be an option if it is available at all; > > when interpolating a small number of points from a large pair of arrays, > > the single sweep through the whole array could dominate the execution > > time. Checking for increasing versus decreasing, in contrast, can be > > done fast, so handling the decreasing case transparently is reasonable. > > > > Eric > > > > > > > > Chuck > > > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion@scipy.org <mailto:NumPy-Discussion@scipy.org> > > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
