[Numpy-discussion] Floor divison on int returns float
njs at pobox.com
Tue Apr 12 22:56:49 EDT 2016
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 : np.int32(2**31 - 1) + np.int32(2**31 - 1)
> Out: -2
> In : type(np.int32(2**31 - 1) + np.int32(2**31 - 1))
> Out: 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.
> 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.
>>> 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.
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion at scipy.org
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion