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 <n...@pobox.com>: > So what type should uint64 + int64 return? > On Apr 12, 2016 7:17 PM, "Antony Lee" <antony....@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 <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 >> >> > _______________________________________________ > 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
