On Thu, Sep 18, 2014 at 6:57 PM, Case Van Horsen 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).

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.)