On Thu, Sep 18, 2014 at 7:16 PM, Alexander Belopolsky

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

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.