[Numpy-discussion] numpy.arange() error?
Thu Feb 9 14:49:27 CST 2012
On Thu, Feb 9, 2012 at 2:47 PM, Eric Firing <firstname.lastname@example.org> 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 : len(np.arange(3.1, 4.9, 0.1))
> >>> Out: 18
> >>> In : len(np.arange(8.1, 9.9, 0.1))
> >>> Out: 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
> > 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
> > (
> > 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
> > 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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion