[Numpy-discussion] Floor divison on int returns float

Antony Lee antony.lee at berkeley.edu
Tue Apr 12 22:17:21 EDT 2016


This kind of issue (see also https://github.com/numpy/numpy/issues/3511)
has become more annoying now that indexing requires integers (indexing with
a float raises a VisibleDeprecationWarning).  The argument "dividing an
uint by an int may give a result that does not fit in an uint nor in an
int" does not sound very convincing to me, after all even adding two
(sized) ints may give a result that does not fit in the same size, but
numpy does not upcast everything there:

In [17]: np.int32(2**31 - 1) + np.int32(2**31 - 1)
Out[17]: -2

In [18]: type(np.int32(2**31 - 1) + np.int32(2**31 - 1))
Out[18]: numpy.int32


I'd think that overflowing operations should just overflow (and possibly
raise a warning via the seterr mechanism), but their possibility should not
be an argument for modifying the output type.

Antony

2016-04-12 17:57 GMT-07:00 T J <tjhnson at gmail.com>:

> Thanks Eric.
>
> Also relevant: https://github.com/numba/numba/issues/909
>
> Looks like Numba has found a way to avoid this edge case.
>
>
>
> On Monday, April 4, 2016, Eric Firing <efiring at hawaii.edu> wrote:
>
>> On 2016/04/04 9:23 AM, T J wrote:
>>
>>> I'm on NumPy 1.10.4 (mkl).
>>>
>>>  >>> np.uint(3) // 2   # 1.0
>>>  >>> 3 // 2   # 1
>>>
>>> Is this behavior expected? It's certainly not desired from my
>>> perspective. If this is not a bug, could someone explain the rationale
>>> to me.
>>>
>>> Thanks.
>>>
>>
>> I agree that it's almost always undesirable; one would reasonably expect
>> some sort of int.  Here's what I think is going on:
>>
>> The odd behavior occurs only with np.uint, which is np.uint64, and when
>> the denominator is a signed int.  The problem is that if the denominator is
>> negative, the result will be negative, so it can't have the same type as
>> the first numerator.  Furthermore, if the denominator is -1, the result
>> will be minus the numerator, and that can't be represented by np.uint or
>> np.int.  Therefore the result is returned as np.float64.  The promotion
>> rules are based on what *could* happen in an operation, not on what *is*
>> happening in a given instance.
>>
>> Eric
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
>> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> https://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20160412/23698391/attachment.html>


More information about the NumPy-Discussion mailing list