Re: [Numpy-discussion] numpy.arange() error?
I think the problem is quite easy to solve, without changing the documentation behaviour. The doc says: Help on built-in function arange in module numpy.core.multiarray: / arange(...) arange([start,] stop[, step,], dtype=None) Return evenly spaced values within a given interval. Values are generated within the half-open interval ``[start, stop)`` (in other words, the interval including `start` but excluding `stop`). For integer arguments the function is equivalent to the Python built-in `range http://docs.python.org/lib/built-in-funcs.html`_ function, but returns a ndarray rather than a list. / stop is exclusive by definition. So substracting a very small value to stop when processing stop I think is the best way. Matteo Il 10/02/2012 02:22, Drew Frank ha scritto: On Thu, Feb 9, 2012 at 3:40 PM, Benjamin Root ben.r...@ou.edu mailto:ben.r...@ou.edu wrote: On Thursday, February 9, 2012, Sturla Molden stu...@molden.no mailto:stu...@molden.no wrote: Den 9. feb. 2012 kl. 22:44 skrev eat e.antero.ta...@gmail.com mailto:e.antero.ta...@gmail.com: Maybe this issue is raised also earlier, but wouldn't it be more consistent to let arange operate only with integers (like Python's range) and let linspace handle the floats as well? Perhaps. Another possibility would be to let arange take decimal arguments, possibly entered as text strings. Sturla Personally, I treat arange() to mean, give me a sequence of values from x to y, exclusive, with a specific step size. Nowhere in that statement does it guarantee a particular number of elements. Whereas linspace() means, give me a sequence of evenly spaced numbers from x to y, optionally inclusive, such that there are exactly N elements. They complement each other well. I agree -- both functions are useful and I think about them the same way. The unfortunate part is that tiny precision errors in y can make arange appear to be sometimes-exclusive rather than always exclusive. I've always imagined there to be a sort of duality between the two functions, where arange(low, high, step) == linspace(low, high-step, round((high-low)/step)) in cases where (high - low)/step is integral, but it turns out this is not the case. There are times when I intentionally will specify a range where the step size will not nicely fit. i.e.- np.arange(1, 7, 3.5). I wouldn't want this to change. Nor would I. What I meant to express earlier is that I like how Matlab addresses this particular class of floating point precision errors, not that I think arange output should somehow include both endpoints. My vote is that if users want matlab-colon-like behavior, we could make a new function - maybe erange() for exact range? Ben Root That could work; it would completely replace arange for me in every circumstance I can think of, but I understand we can't just go changing the behavior of core functions. Drew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion -- --- Matteo Malosio, Eng. Researcher ITIA-CNR (www.itia.cnr.it) Institute of Industrial Technologies and Automation National Research Council via Bassini 15, 20133 MILANO, ITALY Ph: +39 0223699625 Fax: +39 0223699925 e-mail:matteo.malo...@itia.cnr.it --- ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.arange() error?
On Thu, Feb 9, 2012 at 12:20 PM, Drew Frank drewfr...@gmail.com wrote: Eric Firing efiring at hawaii.edu writes: On 02/08/2012 09:31 PM, teomat wrote: Hi, Am I wrong or the numpy.arange() function is not correct 100%? Try to do this: In [7]: len(np.arange(3.1, 4.9, 0.1)) Out[7]: 18 In [8]: len(np.arange(8.1, 9.9, 0.1)) Out[8]: 19 I would expect the same result for each command. Not after more experience with the wonders of floating point! Nice-looking decimal numbers often have long, drawn-out, inexact floating point (base 2) representations. That leads to exactly this sort of problem. numpy.linspace is provided to help get around some of these surprises; or you can use an integer sequence and then scale and shift it. Eric All the best I also found this surprising -- not because I lack experience with floating point, but because I do have experience with MATLAB. In MATLAB, the corresponding operation 3.1:0.1:4.9 has length 19 because of an explicit tolerance parameter used in the implmentation ( http://www.mathworks.com/support/solutions/en/data/1-4FLI96/index.html?solution=1-4FLI96 ). Of course, NumPy is not MATLAB :). That said, I prefer the MATLAB behavior in this case -- even though it has a bit of a magic feel to it, I find it hard to imagine code that operates correctly given the Python semantics and incorrectly under MATLAB's. Thoughts? Matlab didn't have integers, so they did the best they could ;) Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.arange() error?
On 02/09/2012 09:20 AM, Drew Frank wrote: Eric Firingefiringat hawaii.edu writes: On 02/08/2012 09:31 PM, teomat wrote: Hi, Am I wrong or the numpy.arange() function is not correct 100%? Try to do this: In [7]: len(np.arange(3.1, 4.9, 0.1)) Out[7]: 18 In [8]: len(np.arange(8.1, 9.9, 0.1)) Out[8]: 19 I would expect the same result for each command. Not after more experience with the wonders of floating point! Nice-looking decimal numbers often have long, drawn-out, inexact floating point (base 2) representations. That leads to exactly this sort of problem. numpy.linspace is provided to help get around some of these surprises; or you can use an integer sequence and then scale and shift it. Eric All the best I also found this surprising -- not because I lack experience with floating point, but because I do have experience with MATLAB. In MATLAB, the corresponding operation 3.1:0.1:4.9 has length 19 because of an explicit tolerance parameter used in the implmentation (http://www.mathworks.com/support/solutions/en/data/1-4FLI96/index.html?solution=1-4FLI96). Of course, NumPy is not MATLAB :). That said, I prefer the MATLAB behavior in this case -- even though it has a bit of a magic feel to it, I find it hard to imagine code that operates correctly given the Python semantics and incorrectly under MATLAB's. Thoughts? You raise a good point. Neither arange nor linspace provides a close equivalent to the nice behavior of the Matlab colon, even though that is often what one really wants. Adding this, either via an arange kwarg, a linspace kwarg, or a new function, seems like a good idea. Eric ___ 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
Re: [Numpy-discussion] numpy.arange() error?
Hi, On Thu, Feb 9, 2012 at 9:47 PM, Eric Firing efir...@hawaii.edu wrote: On 02/09/2012 09:20 AM, Drew Frank wrote: Eric Firingefiringat hawaii.edu writes: On 02/08/2012 09:31 PM, teomat wrote: Hi, Am I wrong or the numpy.arange() function is not correct 100%? Try to do this: In [7]: len(np.arange(3.1, 4.9, 0.1)) Out[7]: 18 In [8]: len(np.arange(8.1, 9.9, 0.1)) Out[8]: 19 I would expect the same result for each command. Not after more experience with the wonders of floating point! Nice-looking decimal numbers often have long, drawn-out, inexact floating point (base 2) representations. That leads to exactly this sort of problem. numpy.linspace is provided to help get around some of these surprises; or you can use an integer sequence and then scale and shift it. Eric All the best I also found this surprising -- not because I lack experience with floating point, but because I do have experience with MATLAB. In MATLAB, the corresponding operation 3.1:0.1:4.9 has length 19 because of an explicit tolerance parameter used in the implmentation ( http://www.mathworks.com/support/solutions/en/data/1-4FLI96/index.html?solution=1-4FLI96 ). Of course, NumPy is not MATLAB :). That said, I prefer the MATLAB behavior in this case -- even though it has a bit of a magic feel to it, I find it hard to imagine code that operates correctly given the Python semantics and incorrectly under MATLAB's. Thoughts? You raise a good point. Neither arange nor linspace provides a close equivalent to the nice behavior of the Matlab colon, even though that is often what one really wants. Adding this, either via an arange kwarg, a linspace kwarg, or a new function, seems like a good idea. Maybe this issue is raised also earlier, but wouldn't it be more consistent to let arange operate only with integers (like Python's range) and let linspace handle the floats as well? My 2 cents, eat Eric ___ 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.arange() error?
On Thursday, February 9, 2012, Sturla Molden stu...@molden.no wrote: Den 9. feb. 2012 kl. 22:44 skrev eat e.antero.ta...@gmail.com: Maybe this issue is raised also earlier, but wouldn't it be more consistent to let arange operate only with integers (like Python's range) and let linspace handle the floats as well? Perhaps. Another possibility would be to let arange take decimal arguments, possibly entered as text strings. Sturla Personally, I treat arange() to mean, give me a sequence of values from x to y, exclusive, with a specific step size. Nowhere in that statement does it guarantee a particular number of elements. Whereas linspace() means, give me a sequence of evenly spaced numbers from x to y, optionally inclusive, such that there are exactly N elements. They complement each other well. There are times when I intentionally will specify a range where the step size will not nicely fit. i.e.- np.arange(1, 7, 3.5). I wouldn't want this to change. My vote is that if users want matlab-colon-like behavior, we could make a new function - maybe erange() for exact range? Ben Root ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.arange() error?
On Thu, Feb 9, 2012 at 3:40 PM, Benjamin Root ben.r...@ou.edu wrote: On Thursday, February 9, 2012, Sturla Molden stu...@molden.no wrote: Den 9. feb. 2012 kl. 22:44 skrev eat e.antero.ta...@gmail.com: Maybe this issue is raised also earlier, but wouldn't it be more consistent to let arange operate only with integers (like Python's range) and let linspace handle the floats as well? Perhaps. Another possibility would be to let arange take decimal arguments, possibly entered as text strings. Sturla Personally, I treat arange() to mean, give me a sequence of values from x to y, exclusive, with a specific step size. Nowhere in that statement does it guarantee a particular number of elements. Whereas linspace() means, give me a sequence of evenly spaced numbers from x to y, optionally inclusive, such that there are exactly N elements. They complement each other well. I agree -- both functions are useful and I think about them the same way. The unfortunate part is that tiny precision errors in y can make arange appear to be sometimes-exclusive rather than always exclusive. I've always imagined there to be a sort of duality between the two functions, where arange(low, high, step) == linspace(low, high-step, round((high-low)/step)) in cases where (high - low)/step is integral, but it turns out this is not the case. There are times when I intentionally will specify a range where the step size will not nicely fit. i.e.- np.arange(1, 7, 3.5). I wouldn't want this to change. Nor would I. What I meant to express earlier is that I like how Matlab addresses this particular class of floating point precision errors, not that I think arange output should somehow include both endpoints. My vote is that if users want matlab-colon-like behavior, we could make a new function - maybe erange() for exact range? Ben Root That could work; it would completely replace arange for me in every circumstance I can think of, but I understand we can't just go changing the behavior of core functions. Drew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] numpy.arange() error?
On 02/08/2012 09:31 PM, teomat wrote: Hi, Am I wrong or the numpy.arange() function is not correct 100%? Try to do this: In [7]: len(np.arange(3.1, 4.9, 0.1)) Out[7]: 18 In [8]: len(np.arange(8.1, 9.9, 0.1)) Out[8]: 19 I would expect the same result for each command. Not after more experience with the wonders of floating point! Nice-looking decimal numbers often have long, drawn-out, inexact floating point (base 2) representations. That leads to exactly this sort of problem. numpy.linspace is provided to help get around some of these surprises; or you can use an integer sequence and then scale and shift it. Eric All the best ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
