numpy arange includes right hand side

[rshap91]

Not sure if this is a bug or not but i seem to be able to generate an array using np.arange that includes the right hand side...

Reproducing code example:

import numpy as np

np.arange(1,1.5,.1)
# array([1. , 1.1, 1.2, 1.3, 1.4])

np.arange(1,1.6,.1)
# array([1. , 1.1, 1.2, 1.3, 1.4, 1.5, 1.6]) ???

is this the correct behavior?

Error message:

Numpy/Python version information:

1.14.5 3.6.1 |Anaconda 4.4.0 (x86_64)| (default, May 11 2017, 13:04:09)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)]

[eric-wieser]

I think this is a bug, because:

>>> np.arange(1,1.6,.1)[-1]
1.6000000000000005

It seems to me that np.all(arange(start, stop, step) < stop) ought to be an invariant.

This has come up over and over again. arange does some very strange things to compute its values, which strike me as wrong.

[charris]

Note also that '.1' and '1.6' are not true floating point numbers, they can not be exactly represented in IEEE floating point.

[charris]

@eric-wieser

In [5]: floor((1.6 - 1.)/.1)*.1
Out[5]: 0.6000000000000001
...
In [13]: '%20.18f' % 1.6
Out[13]: '1.600000000000000089

arange is simply unreliable for floating point, if "exact" numbers are wanted different methods need to be used.

[eric-wieser]

Representation of decimal numbers aside, I don't think arange should ever produce results beyond its end point. Ignoring numpy arrays, this is trivial to guarantee with:

def arange(start, stop, step):
   x = start
   in_range = (lambda: x > stop) if step < 0 else (lambda: x < stop)
   while in_range():
       yield x
       x += step

Perhaps this approach has other pitfalls.

[seberg]

Well, I would agree that arange (while probably inherently annoying for floats) has pitfalls, call them bugs, that should not be there. But while fixing this one might not hit libraries hard, it could hit a lot of dirty scripts out there very hard.

Edit: but, maybe we could add a futurewarning to it, since I think the only real failure mode is "one too much". That one could say: please please use linspace, and then we are patient, but one day....

[ncgeib]

This is behavior is documented: "For floating point arguments, the length of the result is ceil((stop - start)/step). Because of floating point overflow, this rule may result in the last element of out being greater than stop."

There was a discussion on the mailing list about the details of the arange calculation a while back.

If I remember correctly, the discussion boiled down to: don't use arange for floats. If you know number, spacing and start of the grid points use: x0 + np.arange(N) * dx. If you know number of grid points and the extent of the grid use linspace.

@eric-wieser This approach accumulates error. It is potentially inaccurate.

[eric-wieser]

Thanks for the archaeology, @ncgeib

[Mikea1985]

I just ran into this bug for the first time and was extremely perplexed. Would it be worth having arange spit a warning message when used with floats (the warning could urge the user to use a more predictable method), because I'm sure that many people use it in this "dirty" fashion.

[tabaker99]

Just discovering this. It doesn't make it sound any better to say "it's okay that arange is buggy, because there is a warning in the documentation." If we shouldn't use arange for floats, then arange should reject floats. If it accepts parameters and gives a return value, then it should have stable behavior.