<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 18, 2014 at 1:27 PM, Case Van Horsen <span dir="ltr"><<a href="mailto:casevh@gmail.com" target="_blank">casevh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":1m8" class="" style="overflow:hidden">The ISO C99/C11 (Annex F) (and POSIX and IEEE-754) standards define<br>
a function called "roundToIntegralTowardsNegative". For the special value<br>
+Inf, it specifies a return value of +Inf.<br>
<br>
However, the integral value returned is still an IEEE-754 formatted value<br>
and can return +Inf. PEP-3141 changed the behavior of math.floor() (and<br>
__floor__ in general) to return an actual integer. That makes it impossible<br>
to comply with ISO etc. standards.</div></blockquote></div><br>I don't think there is any dispute over what math.floor(inf) should return.  POSIX, C99, IEEE and probably many other standards agree that inf should be returned as long as the resulting type can represent it.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Note that before math.floor() was changed to return int in 3.x, we had</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">>>> math.floor(float('inf'))</div><div class="gmail_extra">inf</div><div class="gmail_extra"><br></div><div class="gmail_extra">(Python 2.7.8)</div><div class="gmail_extra"><br></div><div class="gmail_extra">The question here is not about floor, but about floor_division.  NumPy implements it as simple-minded floor(x/y), while Python attempts to be more precise by doing floor((x - fmod(x, y))/y).  </div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">$ hg blame -d -u -w Objects/floatobject.c<br></div><div class="gmail_extra">  nascheme Thu Jan 04 01:44:34 2001 +0000: float_divmod(PyObject *v, PyObject *w)<br></div><div class="gmail_extra">..</div><div class="gmail_extra"><div class="gmail_extra">     guido Sun Oct 20 20:16:45 1991 +0000:     mod = fmod(vx, wx);</div><div class="gmail_extra">       tim Sat Sep 16 03:54:24 2000 +0000:     /* fmod is typically exact, so vx-mod is *mathematically* an</div><div class="gmail_extra">     guido Thu May 06 14:26:34 1999 +0000:        exact multiple of wx.  But this is fp arithmetic, and fp</div><div class="gmail_extra">     guido Thu May 06 14:26:34 1999 +0000:        vx - mod is an approximation; the result is that div may</div><div class="gmail_extra">     guido Thu May 06 14:26:34 1999 +0000:        not be an exact integral value after the division, although</div><div class="gmail_extra">     guido Thu May 06 14:26:34 1999 +0000:        it will always be very close to one.</div><div class="gmail_extra">     guido Thu May 06 14:26:34 1999 +0000:     */</div><div class="gmail_extra">     guido Sun Oct 20 20:16:45 1991 +0000:     div = (vx - mod) / wx;</div><div class="gmail_extra">..</div><div class="gmail_extra"><br></div><div class="gmail_extra">Given that this logic dates back to 1991, I doubt not-finite case was seriously considered.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In light of PEP 3141, if anything should be done about float // float it would be to make it return and int and as a consequence inf // 1 should raise an OverflowError.  </div></div></div></div>