Describe the issue:

Given a distance stop - start which very largely outsizes step, np.arange() can produce an array x which has x.size as 1 off the expected size. My guess is that internally, the non-integer result of distance divided by the step (stop - start) / step becomes represented as an "integer" with floating-point representation, and thus does not indicate that one more array element should be generated.

Notably np.arange() with float arguments has a great many related issues—it looks like the inprecision in those scenarios seems to be considered "acceptable behaviour" and has been noted in the docs as such. However as in #18881, because the dtype is specified as an integer, people might have different thoughts. cc @asmeurer

I found this via a Hypothesis-powered test method I wrote for the Array API test suite.

Reproduce the code example:

>>> start, stop, step = 0, 108086391056891901, 1080863910568919
>>> x = np.arange(start, stop, step, dtype=np.uint64)
>>> x.size
100
>>> r = range(start, stop, step)
>>> len(r)
101
...
>>> x[-1]
107005527146322981
>>> x[-1] + np.uint64(step)
108086391056891900  # i.e. 1 less than stop
...
>>> 108086391056891901 == 100 * 1080863910568919 + 1
True
>>> n = 108086391056891901 / 1080863910568919
>>> n
100.0
>>> n.is_integer()
True

NumPy/Python version information:

0.3.0+27065.g0169af739 3.8.10 (default, Sep 28 2021, 16:10:42) 
[GCC 9.3.0]