[Python-ideas] What math.floor(inf) should return? Was: Make `float('inf') //1 == float('inf')`

[Case Van Horsen]

On Thu, Sep 18, 2014 at 7:16 PM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
>
> On Thu, Sep 18, 2014 at 6:57 PM, Case Van Horsen <casevh at gmail.com> wrote:
>>
>> > 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.
>>
>> I dispute that there is no dispute over what math.floor(inf) should
>> return. ;-)
>>
>
> I am changing the subject so that we don't mix making new decisions with a
> critique and defense of the decisions that were made in the past.
>
> I wrote: "inf should be returned as long as the resulting type can represent
> it".  This is the part that I still believe is not disputed.   No one has
> suggested that math.floor(inf)  should return nan, for example.
>
>
>> All the standards specify a result type can represent +-Inf and +-0. A
>> standards compliant version should return +-Inf and +-0.  lrint() and
>> llrint()
>> are defined to return long or long long, respectively. It would be fine if
>> they raised an exception. The current math.floor() actually behaves more
>> like llrint() than floor().
>>
>
> POSIX does not preclude raising an exception: "If the correct value would
> cause overflow, a range error shall occur"
> (http://pubs.opengroup.org/onlinepubs/009695399/functions/floor.html).
Under the section RETURN VALUE, it also states:

If x = +-0 or +-Inf, then x shall be returned.

And under APPLICATION USAGE, it states:

The floor() function can only overflow when the floating-point
 representation has DBL_MANT_DIG > DBL_MAX_EXP.
>
>>
>> I accept that having math.floor() return an integer (and raise an
>> exception
>> for +-Inf) may be useful in many cases but it is different from the
>> standard.
>> Other floating-point libraries still return a floating-point value.
>
> The standards are influenced by the limitation inherent in many languages
> where ints have finite range and cannot represent floor() of many finite
> floating point values.  Python does not have this limitation.  (Granted -
> PEP 3141 could do a better job explaining why floor, ceil, round, //, etc.
> should return Integer rather than Real.)

For ceil, trunc, and floor, I can't think of any situation where returning
an integer is more "precise" than returning a float. Assuming standard
IEEE 64-bit format, only the first 53 bits will be significant. The
remaining bits will just be 0. (If there is a counter-example, please
let me know. I know enough about floating-point to know I don't
very much about floating-point. ;-) )

I appreciate that returning an Integral value can make using the result
of floor(), etc., easier by eliminating the need for int(floor()) but I think
it adds a false sense of precision and changes the behavior of
math.floor() for +-0 and +-Inf.

Even though I don't think it is worth changing, I can think of two
options.

1) Add trunc, ceil, floor as reserved works (just like round) and let
them call the methods defined by PEP-3141. Then math.floor() can
revert back to returning a float.

2) Add an alternate math library, say stdmath, (or ieeemath or...)
that can follow a different set of rules than the math module. In
addition to the functions provided by the math module, it could
define additional functions such as stdmath.div such that
stdmath.div(2.0, 0) return Inf instead of raising an exception.