<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 2, 2014 at 10:12 PM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Oct 2, 2014 at 9:29 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On Fri, Oct 3, 2014 at 3:20 AM, Charles R Harris<br>
<<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>> wrote:<br>
><br>
> On Thu, Oct 2, 2014 at 7:06 PM, Benjamin Root <<a href="mailto:ben.root@ou.edu" target="_blank">ben.root@ou.edu</a>> wrote:<br>
>><br>
>> Out[1] has an integer divided by an integer, and you can't represent nan<br>
>> as an integer. Perhaps something weird was happening with type promotion<br>
>> between versions?<br>
><br>
><br>
> Also note that in python3 the '/' operator does float rather than integer<br>
> division.<br>
><br>
>>>> np.array(0) / np.array(0)<br>
> __main__:1: RuntimeWarning: invalid value encountered in true_divide<br>
> nan<br>
<br>
</div></div>Floor division still acts the same though:<br>
<br>
>>> np.array(0) // np.array(0)<br>
__main__:1: RuntimeWarning: divide by zero encountered in floor_divide<br>
0<br>
<br>
The seterr warning system makes a lot of sense for IEEE754 floats,<br>
which are specifically designed so that 0/0 has a unique well-defined<br>
answer. For ints though this seems really broken to me. 0 / 0 = 0 is<br>
just the wrong answer. It would be nice if we had something reasonable<br>
to return, but we don't, and I'd rather raise an error than return the<br>
wrong answer.<br></blockquote><div><br></div></span><div>That's an option, although arguable for arrays of numbers. However, the fact that we don't know *which* numbers caused the problem strengthens the argument for an error.<br><br></div></div></div></div></blockquote><div><br></div><div>Plus the g*dawful warning default to only warn once. That has always bothered me, it just seems useless.<br><br></div><div>Chuck<br></div><div><br></div></div></div></div>