[Numpy-discussion] floats for indexing, reshape - too strict ?

[josef.pktd at gmail.com]

On Wed, Jul 1, 2015 at 10:32 AM, Sebastian Berg <sebastian at sipsolutions.net>
wrote:

> On Mi, 2015-07-01 at 10:05 -0400, josef.pktd at 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 at scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20150701/e59202b2/attachment.html>