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
