suggested change of behavior for interp
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).
Jon ________________________________________________________ Jonathan D. Slavin Harvard-Smithsonian CfA jslavin@cfa.harvard.edu 60 Garden Street, MS 83 phone: (617) 496-7981 Cambridge, MA 02138-1516 fax: (617) 496-7577 USA ________________________________________________________
On Tue, Jun 4, 2013 at 12:07 PM, Slavin, Jonathan jslavin@cfa.harvard.eduwrote:
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.
Chuck
On 2013/06/04 2:05 PM, Charles R Harris wrote:
On Tue, Jun 4, 2013 at 12:07 PM, Slavin, Jonathan <jslavin@cfa.harvard.edu mailto:jslavin@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
Could non-monotonicity be detected as part of the interp process? Perhaps a sign switch in the deltas?
I have been bitten by this problem too.
Cheers! Ben Root
On Jun 4, 2013 9:08 PM, "Eric Firing" efiring@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 <jslavin@cfa.harvard.edu mailto:jslavin@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 http://mail.scipy.org/mailman/listinfo/numpy-discussion
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" <efiring@hawaii.edu mailto:efiring@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 <jslavin@cfa.harvard.edu mailto:jslavin@cfa.harvard.edu
<mailto:jslavin@cfa.harvard.edu mailto:jslavin@cfa.harvard.edu>> wrote:
Hi, I would like to suggest that the behavior of numpy.interp bechanged
regarding treatment of situations in which the x-coordinatesare 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, providingincorrect
values. This fix could be as simple as a monotonicity test and inversion if necessary (plus a raise statement fornon-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
On 5 Jun 2013 03:21, "Eric Firing" efiring@hawaii.edu wrote:
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.
Nonetheless, perhaps the function should at least be safe by default? I'm worried by these multiple reports of people silently getting wrong answers in practice...
-n
participants (5)
-
Benjamin Root -
Charles R Harris -
Eric Firing -
Nathaniel Smith -
Slavin, Jonathan