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 <tjhn...@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 <efir...@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@scipy.org >> https://mail.scipy.org/mailman/listinfo/numpy-discussion >> > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
