On Wed, Jul 1, 2015 at 10:32 AM, Sebastian Berg <sebast...@sipsolutions.net> wrote:
> 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. > Yes, I thought about this, something like `int_if_close` in analogy to real_if_close would be useful. However, given that we need to decide on a threshold in this case, I thought it's overkill to put that into reshape, ones and indexing and similar. Simpler cases would work number if triangular elements >>> for i in range(10): print(i, i * (i - 1) / 2. == int(i * (i - 1) / 2.)) 0 True 1 True 2 True 3 True 4 True 5 True 6 True 7 True 8 True 9 True also np.ceil and np.trunc return floats, not integers. One disadvantage of raising or warning after the equality check is that developers have a tendency to write "nice" unit tests. Then the casting doesn't break in the unit tests but might raise an exception at some random data. For reference: here are my changes in cleaning up https://github.com/statsmodels/statsmodels/pull/2490/files Josef > > - 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 > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion