<p dir="ltr">So what type should uint64 + int64 return?</p>
<div class="gmail_quote">On Apr 12, 2016 7:17 PM, "Antony Lee" <<a href="mailto:antony.lee@berkeley.edu">antony.lee@berkeley.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This kind of issue (see also <a href="https://github.com/numpy/numpy/issues/3511" target="_blank">https://github.com/numpy/numpy/issues/3511</a>) 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:<div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><span style="font-family:monospace"><span style="color:rgb(24,178,24)">In [</span><span style="font-weight:bold;color:rgb(84,255,84)">17</span><span style="color:rgb(24,178,24)">]: </span><span style="color:rgb(0,0,0)">np.int32(2**31 - 1) + np.int32(2**31 - 1) </span></span></div><div><span style="font-family:monospace"><span style="color:rgb(178,24,24)">Out[</span><span style="font-weight:bold;color:rgb(255,84,84)">17</span><span style="color:rgb(178,24,24)">]: </span><span style="color:rgb(0,0,0)">-2
</span></span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"><span style="color:rgb(24,178,24)">In [</span><span style="font-weight:bold;color:rgb(84,255,84)">18</span><span style="color:rgb(24,178,24)">]: </span><span style="color:rgb(0,0,0)">type(np.int32(2**31 - 1) + np.int32(2**31 - 1))
</span></span></div><div><span style="font-family:monospace"><span style="color:rgb(178,24,24)">Out[</span><span style="font-weight:bold;color:rgb(255,84,84)">18</span><span style="color:rgb(178,24,24)">]: </span><span style="color:rgb(0,0,0)">numpy.int32</span></span></div></blockquote><font color="#000000" face="monospace"><br></font><div><font color="#000000" face="arial, helvetica, sans-serif">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.</font></div><div><font color="#000000" face="arial, helvetica, sans-serif"><br></font></div><div><font color="#000000" face="arial, helvetica, sans-serif">Antony</font></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-04-12 17:57 GMT-07:00 T J <span dir="ltr"><<a href="mailto:tjhnson@gmail.com" target="_blank">tjhnson@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks Eric.<div><br></div><div>Also relevant: <a href="https://github.com/numba/numba/issues/909" target="_blank">https://github.com/numba/numba/issues/909</a></div><div><br></div><div>Looks like Numba has found a way to avoid this edge case.</div><div><div><div><br></div><div><br><br>On Monday, April 4, 2016, Eric Firing <<a href="mailto:efiring@hawaii.edu" target="_blank">efiring@hawaii.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2016/04/04 9:23 AM, T J wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm on NumPy 1.10.4 (mkl).<br>
<br>
>>> np.uint(3) // 2 # 1.0<br>
>>> 3 // 2 # 1<br>
<br>
Is this behavior expected? It's certainly not desired from my<br>
perspective. If this is not a bug, could someone explain the rationale<br>
to me.<br>
<br>
Thanks.<br>
</blockquote>
<br>
I agree that it's almost always undesirable; one would reasonably expect some sort of int. Here's what I think is going on:<br>
<br>
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 <a href="http://np.int" target="_blank">np.int</a>. 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.<br>
<br>
Eric<br>
<br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a>NumPy-Discussion@scipy.org</a><br>
<a href="https://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">https://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org" target="_blank">NumPy-Discussion@scipy.org</a><br>
<a href="https://mail.scipy.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="https://mail.scipy.org/mailman/listinfo/numpy-discussion" rel="noreferrer" target="_blank">https://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
<br></blockquote></div>