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 xcoordinates are not monotonically increasing. Specifically, it seems to me that interp should work correctly when the xcoordinate is decreasing monotonically. Clearly it cannot work if the xcoordinate 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 nonmonotonic cases).
Jon ________________________________________________________ Jonathan D. Slavin HarvardSmithsonian CfA jslavin@cfa.harvard.edu 60 Garden Street, MS 83 phone: (617) 4967981 Cambridge, MA 021381516 fax: (617) 4967577 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 xcoordinates are not monotonically increasing. Specifically, it seems to me that interp should work correctly when the xcoordinate is decreasing monotonically. Clearly it cannot work if the xcoordinate 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 nonmonotonic 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 xcoordinates are not monotonically increasing. Specifically, it seems to me that interp should work correctly when the xcoordinate is decreasing monotonically. Clearly it cannot work if the xcoordinate 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 nonmonotonic 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 nonmonotonicity 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 xcoordinates are not monotonically increasing. Specifically, it seems to me that interp should work correctly when the xcoordinate is decreasing monotonically. Clearly it cannot work if the xcoordinate 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 nonmonotonic
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
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On 2013/06/04 4:15 PM, Benjamin Root wrote:
Could nonmonotonicity 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 precomputed in a single sweep. Nonmonotonicity 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 be
changed
regarding treatment of situations in which the xcoordinates
are not
monotonically increasing. Specifically, it seems to me that interp should work correctly when the xcoordinate is decreasing monotonically. Clearly it cannot work if the xcoordinate 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
nonmonotonic 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
NumPyDiscussion mailing list NumPyDiscussion@scipy.org mailto:NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On 5 Jun 2013 03:21, "Eric Firing" efiring@hawaii.edu wrote:
On 2013/06/04 4:15 PM, Benjamin Root wrote:
Could nonmonotonicity 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 precomputed in a single sweep. Nonmonotonicity 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