[Numpy-discussion] Floor divison on int returns float
Antony Lee
antony.lee at berkeley.edu
Wed Apr 13 00:26:19 EDT 2016
Whatever the C rules are (which I don't know off the top of my head, but I
guess it must be one of uint64 or int64). It's not as if conversion to
float64 was lossless:
In [38]: 2**63 - (np.int64(2**62-1) + np.uint64(2**62-1))
Out[38]: 0.0
Note that the result of (np.int64(2**62-1) + np.uint64(2**62-1)) would
actually fit in an int64 (or an uint64), so arguably the conversion to
float makes things worse.
Antony
2016-04-12 19:56 GMT-07:00 Nathaniel Smith <njs at pobox.com>:
> So what type should uint64 + int64 return?
> On Apr 12, 2016 7:17 PM, "Antony Lee" <antony.lee at berkeley.edu> wrote:
>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/02e09352/attachment.html>
More information about the NumPy-Discussion
mailing list