linspace handling of extra return
While working on something else, I realized that linspace is not handling requests for returning the sampling spacing consistently:
np.linspace(0, 1, 3, retstep=True) (array([ 0. , 0.5, 1. ]), 0.5) np.linspace(0, 1, 1, retstep=True) array([ 0.]) np.linspace(0, 1, 0, retstep=True) array([], dtype=float64)
Basically, retstep is ignored if the number of samples is 0 or 1. One could argue that it makes sense, because those sequences do not have a spacing defined. But at the very least it should be documented as doing so, and the following inconsistency removed:
np.linspace(0, 1, 1, endpoint=True, retstep=True) array([ 0.]) np.linspace(0, 1, 1, endpoint=False, retstep=True) (array([ 0.]), 1.0)
I am personally inclined to think that if a step is requested, then a step should be returned, and if it cannot be calculated in a reasonable manner, then a placeholder such as None, nan, 0 or stop - start should be returned. What does the collective wisdom think is the best approach for this? Jaime -- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.
Oh, wow. I never noticed that before. Yeah, if I state that retstep=True, then I am coding my handling to expect two values to be returned, not 1. I think it should be nan, but I could also agree with zero. It should definitely remain a float value, though. Cheers! Ben Root On Tue, Jan 13, 2015 at 10:15 AM, Jaime Fernández del Río < jaime.frio@gmail.com> wrote:
While working on something else, I realized that linspace is not handling requests for returning the sampling spacing consistently:
np.linspace(0, 1, 3, retstep=True) (array([ 0. , 0.5, 1. ]), 0.5) np.linspace(0, 1, 1, retstep=True) array([ 0.]) np.linspace(0, 1, 0, retstep=True) array([], dtype=float64)
Basically, retstep is ignored if the number of samples is 0 or 1. One could argue that it makes sense, because those sequences do not have a spacing defined. But at the very least it should be documented as doing so, and the following inconsistency removed:
np.linspace(0, 1, 1, endpoint=True, retstep=True) array([ 0.]) np.linspace(0, 1, 1, endpoint=False, retstep=True) (array([ 0.]), 1.0)
I am personally inclined to think that if a step is requested, then a step should be returned, and if it cannot be calculated in a reasonable manner, then a placeholder such as None, nan, 0 or stop - start should be returned.
What does the collective wisdom think is the best approach for this?
Jaime
-- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Jan 13, 2015 at 7:23 AM, Benjamin Root <ben.root@ou.edu> wrote:
Oh, wow. I never noticed that before. Yeah, if I state that retstep=True, then I am coding my handling to expect two values to be returned, not 1. I think it should be nan, but I could also agree with zero. It should definitely remain a float value, though.
NaN it is then: the change and supporting tests are now part of gh-5446. Jaime
Cheers! Ben Root
On Tue, Jan 13, 2015 at 10:15 AM, Jaime Fernández del Río < jaime.frio@gmail.com> wrote:
While working on something else, I realized that linspace is not handling requests for returning the sampling spacing consistently:
np.linspace(0, 1, 3, retstep=True) (array([ 0. , 0.5, 1. ]), 0.5) np.linspace(0, 1, 1, retstep=True) array([ 0.]) np.linspace(0, 1, 0, retstep=True) array([], dtype=float64)
Basically, retstep is ignored if the number of samples is 0 or 1. One could argue that it makes sense, because those sequences do not have a spacing defined. But at the very least it should be documented as doing so, and the following inconsistency removed:
np.linspace(0, 1, 1, endpoint=True, retstep=True) array([ 0.]) np.linspace(0, 1, 1, endpoint=False, retstep=True) (array([ 0.]), 1.0)
I am personally inclined to think that if a step is requested, then a step should be returned, and if it cannot be calculated in a reasonable manner, then a placeholder such as None, nan, 0 or stop - start should be returned.
What does the collective wisdom think is the best approach for this?
Jaime
-- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.
_______________________________________________ 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
-- (\__/) ( O.o) ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de dominación mundial.
On Tue, Jan 13, 2015 at 7:23 AM, Benjamin Root <ben.root@ou.edu> wrote:
Oh, wow. I never noticed that before. Yeah, if I state that retstep=True, then I am coding my handling to expect two values to be returned, not 1. I think it should be nan, but I could also agree with zero. It should definitely remain a float value, though.
How about a ValueError? -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
So, raise a ValueError when it used to return (mostly) correct results? For some reason, I don't think people would appreciate that. Ben Root On Jan 13, 2015 5:59 PM, "Chris Barker" <chris.barker@noaa.gov> wrote:
On Tue, Jan 13, 2015 at 7:23 AM, Benjamin Root <ben.root@ou.edu> wrote:
Oh, wow. I never noticed that before. Yeah, if I state that retstep=True, then I am coding my handling to expect two values to be returned, not 1. I think it should be nan, but I could also agree with zero. It should definitely remain a float value, though.
How about a ValueError?
-CHB
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Tue, Jan 13, 2015 at 7:02 PM, Benjamin Root <ben.root@ou.edu> wrote:
So, raise a ValueError when it used to return (mostly) correct results? For some reason, I don't think people would appreciate that.
Ben Root On Jan 13, 2015 5:59 PM, "Chris Barker" <chris.barker@noaa.gov> wrote:
On Tue, Jan 13, 2015 at 7:23 AM, Benjamin Root <ben.root@ou.edu> wrote:
Oh, wow. I never noticed that before. Yeah, if I state that retstep=True, then I am coding my handling to expect two values to be returned, not 1. I think it should be nan, but I could also agree with zero. It should definitely remain a float value, though.
How about a ValueError?
-CHB
How about raising ValueError if num < 0 or num == 1, endpoint=True, and start != stop? Chuck
On Tue, Jan 13, 2015 at 6:02 PM, Benjamin Root <ben.root@ou.edu> wrote:
So, raise a ValueError when it used to return (mostly) correct results?
my understanding is that it was NOT returning mostly correct results, it was returning completely different results for those special values: a 2-tuple in most cases, a single array if there delta didn't make sense. That may be correct, but it's not a result ;-) That being said, I'm sure some folks have written work-arounds that would break if this were changed. A bug is always incorporated in someones workflow. http://xkcd.com/1172/ Though if you do have a work-around for when the step is not returned, it will likely break if suddenly zero or NaN is returned, as well. So I'm not sure there is a fully backward compatible fix. -CHB
For some reason, I don't think people would appreciate that.
Ben Root On Jan 13, 2015 5:59 PM, "Chris Barker" <chris.barker@noaa.gov> wrote:
On Tue, Jan 13, 2015 at 7:23 AM, Benjamin Root <ben.root@ou.edu> wrote:
Oh, wow. I never noticed that before. Yeah, if I state that retstep=True, then I am coding my handling to expect two values to be returned, not 1. I think it should be nan, but I could also agree with zero. It should definitely remain a float value, though.
How about a ValueError?
-CHB
--
Christopher Barker, Ph.D. Oceanographer
Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@noaa.gov
_______________________________________________ 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
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
participants (4)
-
Benjamin Root -
Charles R Harris -
Chris Barker -
Jaime Fernández del Río