On Mi, 2015-07-01 at 10:05 -0400, josef.p...@gmail.com wrote: > About the deprecation warning for using another type than integers, in > ones, reshape, indexing and so on: > > > Wouldn't it be nicer to accept floats that are equal to an integer? >
Hmmm, the biggest point was that the old solution was to basically (besides strings) use `int(...)`, which means it does not raise any errors as you also mention. I am open to think about allowing exact floats for most of this (frankly, not advanced indexing at least for the moment, but we never did there), I think scipy may be doing that for some functions? The disadvantage I see is, that some weirder calculations would possible work most of the times, but not always, what I mean is such a case. A -- possibly silly -- example: In [8]: for i in range(10): ...: print i, i == i * 0.1 * 10 ...: 0 True 1 True 2 True 3 False 4 True 5 True 6 False 7 False 8 True 9 True I am somewhat opposed to rounding a lot (i.e. not noticing if you got 3.3333 somewhere), so not sure if you can define a "tolerance" reasonable here unless it is exact. Though I guess you are right that `//` will also just round silently already. - Sebastian > > for example > > > >>> 5.0 == 5 > True > > > >>> np.ones(10 / 2) > array([ 1., 1., 1., 1., 1.]) > >>> 10 / 2 == 5 > True > > > or the python 2 version > > > >>> np.ones(10. / 2) > array([ 1., 1., 1., 1., 1.]) > >>> 10. / 2 == 5 > True > > > I'm using now 10 // 2, or int(10./2 + 1) but this is unconditional > and doesn't raise if the numbers are not close or equal to an integer > (which would be a bug) > > > > > Josef > > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
