thouis / numpy-trac-migration

numpy Trac to github issues migration
2 stars 3 forks source link

arange using float for step and integer dtype results in an array with all values being the same (Trac #1864) #5662

Open numpy-gitbot opened 12 years ago

numpy-gitbot commented 12 years ago

Original ticket http://projects.scipy.org/numpy/ticket/1864 on 2011-06-10 by atmention:bsouthey, assigned to unknown.

When using a float step but a integer dtype, np.arange appears to full the array with a constant value (first value in the range) rather than an integer array of different integers or giving an error. The following code illustrates the problem:

>>> import numpy as np
>>> np.__version__
'2.0.0.dev-a1e7be3'
>>> np.arange(0.,5.,0.5)
array([ 0. ,  0.5,  1. ,  1.5,  2. ,  2.5,  3. ,  3.5,  4. ,  4.5])
>>> np.arange(0.,5.,0.5, dtype=int)
array([0, 0, 0, 0, 0, 0, 0, 0, 0, 0])
>>> np.asarray(np.arange(0.,5.,0.5), dtype=int)
array([0, 0, 1, 1, 2, 2, 3, 3, 4, 4])
numpy-gitbot commented 12 years ago

atmention:dhomeier wrote on 2011-06-14

Actually it seems to construct something like np.arange(int(start), int(stop), int(step)), although the length remains the same as for the float array - compare

>>>np.arange(0,5,1.5, dtype=int)
array([0, 1, 2, 3])

np.arange().astype(int) would produce what you may expect, but I'm not sure if this should be considered a feature or a bug. It provides something neither np.arange(int(start), int(stop), int(step)) nor np.arange(start, stop, step).astype(int) could construct, though I cannot think of any situation where one could use this...

numpy-gitbot commented 12 years ago

atmention:bsouthey wrote on 2011-06-15

Replying to [comment:1 derek]:

Actually it seems to construct something like np.arange(int(start), int(stop), int(step)), although the length remains the same as for the float array - compare {{{

np.arange(0,5,1.5, dtype=int) array([0, 1, 2, 3]) }}}

Actually that is not the expected output either because it is dropping the last element(s) as seen when ignoring the 'dtype' (with numpy 1.6.1rc1):

>>> np.arange(0,5,1.5)
array([ 0. ,  1.5,  3. ,  4.5])
>>> np.arange(0,5,1.5).astype(int)
array([0, 1, 3, 4])
>>> np.arange(0,20,1.5, dtype=int)
array([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13])

Initially I thought that np.arange(start, stop, step, dtype=int) should be the same as np.arange(start, stop, step).astype(int). But really it should infer the correct output dtype from all of the inputs and let the user recast the dtype as needed.

numpy-gitbot commented 12 years ago

atmention:dhomeier wrote on 2011-06-15

Replying to [comment:2 bsouthey]:

Actually that is not the expected output either because it is dropping the last element(s) as seen when ignoring the 'dtype' (with numpy 1.6.1rc1):

>>> np.arange(0,20,1.5, dtype=int)
 array([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10, 11, 12, 13])

That's (I think) what I meant by "the length remains the same", or more precisely, it still has the same shape as np.arange(0,20,1.5, dtype=float).

Initially I thought that np.arange(start, stop, step, dtype=int) should be the same as np.arange(start, stop, step).astype(int). But really it should infer the correct output dtype from all of the inputs and let the user recast the dtype as needed.

You mean it first should compute np.arange(int(start), int(stop), int(step)), and leave it to the user to apply astype() afterwards if so desired? Still I am not sure this would be more useful behaviour, e.g. in your original example you'd get a ZeroDivisionError.