[Python-ideas] Fwd: Make `float('inf') //1 == float('inf')`

[Alexander Belopolsky]

On Thu, Sep 18, 2014 at 1:27 PM, Case Van Horsen <casevh at gmail.com> 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 impossible
> 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

>>> math.floor(float('inf'))
inf

(Python 2.7.8)

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,
PyObject *w)
..
     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
seriously considered.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140918/7a08ffd5/attachment-0001.html>