<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 18, 2014 at 1:30 PM, Jonathan Helmus <span dir="ltr"><<a href="mailto:jjhelmus@gmail.com" target="_blank">jjhelmus@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><div>On 09/18/2014 12:44 PM, Petr Viktorin wrote:<br>
> On Thu, Sep 18, 2014 at 7:14 PM, Jonathan Helmus <<a href="mailto:jjhelmus@gmail.com" target="_blank">jjhelmus@gmail.com</a>> wrote:<br>
>> On 09/18/2014 12:01 PM, Chris Barker wrote:<br>
>><br>
>> Well,<br>
>><br>
>> First of all, numpy and the python math module have a number of differences<br>
>> when it comes to handling these kind of special cases -- and I think that:<br>
>><br>
>> 1) numpy needs to do what makes the most sense for numpy and NOT mirror the<br>
>> math lib.<br>
> Sure.<br>
><br>
>> 2) the use-cases of the math lib and numpy are different, so they maybe<br>
>> _should_ have different handling of this kind of thing.<br>
> If you have a reason for the difference, I'd like to hear it.<br>
><br>
>> 3) I'm not sure that the core devs think these kinds of issues are "wrong"<br>
>> 'enough to break backward compatibility in subtle ways.<br>
> I'd be perfectly fine with it being documented and tested (in CPython)<br>
> as either a design mistake or design choice.<br>
><br>
>> But it's a fun topic in any case, and maybe numpy's behavior could be<br>
>> improved.<br>
>>> My vote is that NumPy is correct here. I see no reason why<br>
>>>>>> float('inf') / 1<br>
>>> and<br>
>>>>>> float('inf') // 1<br>
>>> should return different results.<br>
>><br>
>> Well, one argument is that "floor division" is supposed to return an integer<br>
>> value, and that inf is NOT an integer value. The integral part of infinity<br>
>> doesn't exist and thus is Not a Number.<br>
>><br>
>><br>
>> But nan is not an integer value either:<br>
>><br>
>>>>> float('inf') // 1<br>
>> nan<br>
>>>>> int(float('inf') // 1)<br>
>> Traceback (most recent call last):<br>
>>    File "<stdin>", line 1, in <module><br>
>> ValueError: cannot convert float NaN to integer<br>
>><br>
>> Perhaps float('inf') // 1 should raise a ValueError directly since there is<br>
>> no proper way perform the floor division on infinity.<br>
> inf not even a *real* number; a lot of operations don't make<br>
> mathematical sense on it. But most are defined anyway, and quite<br>
> sanely.<br>
<br>
</div></div>But in IEEE-754 inf is a valid floating point number (where-as NaN is<br>
not) and has well defined arithmetic, specifically inf / 1 == inf and<br>
RoundToIntergral(inf) == inf.  In the numpy example, the<br>
numpy.array(float('inf')) statement creates an array containing a<br>
float32 or float64 representation of inf.  After this I would expect a<br>
floor division to return inf since that is what IEEE-754 arithmetic<br>
specifies.<br>
<br>
For me the question is if the floor division should also perform a cast<br>
to an integer type. Since inf cannot be represented in most common<br>
integer formats this should raise an exception.  Since // does not<br>
normally perform a cast, for example type(float(5) // 2) == float, the<br>
point is mute.<br>
<br>
The real question is if Python floats follows IEEE-754 arithmetic or<br>
not.  If they do not what standard are they going to follow?<br>
<span><font color="#888888"><br>
     - Jonathan Helmus<br>
</font></span><div><div>_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org" target="_blank">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra">Agreed. It's definitely best to follow the IEEE conventions. That will be the most commonly expected behavior, especially in ambiguous cases like this.</div><div class="gmail_extra">-Ian Henriksen</div></div>