[Numpy-discussion] numpy.arange() error?

Tony Yu tsyu80@gmail....
Thu Feb 9 14:49:27 CST 2012


On Thu, Feb 9, 2012 at 2:47 PM, Eric Firing <efiring@hawaii.edu> wrote:

> On 02/09/2012 09:20 AM, Drew Frank 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?
>
> 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
>
>
On a related note: would an `endpoint` parameter for `arange` be desirable?
For example, `linspace` already has this as a parameter.

When using `arange` with int values, I often want the endpoint. Of course,
adding 1 is easy to do (and shorter), but in some ways it's less readable
(are you adding 1 because the variable itself is off by 1 or because of the
fact the limit is exclusive; sometimes I end up adding 2 because both are
true). It's a subtle difference, I know. And it's debatable whether
`endpoint` would be more readable (though I think it is).

This is somewhat tangential to how `arange` behaves with floats, in which
the second limit sometimes *appears* inclusive and sometimes *appears*
exclusive. I never use `arange` with floats because of this unpredictably,
so I like the idea of adding a tolerance.

-Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20120209/09639dfc/attachment.html 


More information about the NumPy-Discussion mailing list