On Sep 18, 2014 12:31 PM, "Alexander Belopolsky" < email@example.com> wrote:
On Thu, Sep 18, 2014 at 1:27 PM, Case Van Horsen firstname.lastname@example.org wrote:
The ISO C99/C11 (Annex F) (and POSIX and IEEE-754) standards define a function called "roundToIntegralTowardsNegative". For the special value +Inf, it specifies a return value of +Inf.
However, the integral value returned is still an IEEE-754 formatted value and can return +Inf. PEP-3141 changed the behavior of math.floor() (and __floor__ in general) to return an actual integer. That makes it
to comply with ISO etc. standards.
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.
Note that before math.floor() was changed to return int in 3.x, we had
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).
$ hg blame -d -u -w Objects/floatobject.c nascheme Thu Jan 04 01:44:34 2001 +0000: float_divmod(PyObject *v,
.. guido Sun Oct 20 20:16:45 1991 +0000: mod = fmod(vx, wx); tim Sat Sep 16 03:54:24 2000 +0000: /* fmod is typically
exact, so vx-mod is *mathematically* an
guido Thu May 06 14:26:34 1999 +0000: exact multiple of wx.
But this is fp arithmetic, and fp
guido Thu May 06 14:26:34 1999 +0000: vx - mod is an
approximation; the result is that div may
guido Thu May 06 14:26:34 1999 +0000: not be an exact
integral value after the division, although
guido Thu May 06 14:26:34 1999 +0000: it will always be very
close to one.
guido Thu May 06 14:26:34 1999 +0000: */ guido Sun Oct 20 20:16:45 1991 +0000: div = (vx - mod) / wx;
Given that this logic dates back to 1991, I doubt not-finite case was
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.