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

[Charles R Harris]

On Thu, Feb 9, 2012 at 12:20 PM, Drew Frank <drewfrank at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120209/fd2fc056/attachment.html>