[Python-Dev] [Python-checkins] r51525 - in python/trunk: Lib/test/test_float.py Objects/floatobject.c

[Alex Martelli]

On Aug 23, 2006, at 3:29 PM, Thomas Wouters wrote:

>
> Since Alex isn't on python-dev, forwarding this for his convenience  
> (he said he wanted to reply.)

Thanks!  I _am_ on Python-Dev (otherwise couldn't read what you're  
forwarding here), but not on Python-Checkins (where the discussion  
was started).

> Tim also replied to his checkin, but I didn't forward that message.

Yep, saw that (thanks Brett) -- if I read him right, Tim was  
basically suggesting better ways to check for infinity rather than  
saying it's better to keep today's inconsistency (he can surely  
correct me if I misread).  Tim is of course right, but PEP 754 (the  
fpconst module) would appear to be the right way to perform the  
checking, anyway.

> I don't think this can be right. The returnvalue of pow() in the  
> case of ERANGE isn't defined anywhere that I can find, at least.  
> How can we assume it is +Infinity? As I tried to say over the  
> visiphone, you can't even use compile-

That's how I read ISO/IEC 9899:1999 7.12.1.4 , which is describing  
C's <math> functions in general:

"""
If a floating result overflows and default rounding is in effect, or  
if the mathematical result is an exact infinity (for example log 
(0.0)), then the function returns the value of the macro HUGE_VAL,  
HUGE_VALF, or HUGE_VALL according to the return type, with the same  
sign as the correct value of the function;
"""
etc.

Yes, that's a C language standard that's just 7 years old, rather  
than the 16-years-old standard Python can "definitely" count on; but  
we could presumably test (and rely on) __STDC_IEC_559__ if we need  
features in Appendix F, or just on __STDC_VERSION__ being defined and  
 >= 199901L for more generic parts of the standard (such as the part  
I was quoting above from chapter 7).  People who build Python with C  
compilers not meeting these macro criteria but still "good enough" to  
afford a minimally functional implementation of IEEE 754 floats might  
run configure with some appropriate -with-whatever options to assert  
the fact, if needed (i.e., if either because of C 1990 Standard  
language, or realworld brokenness of important compilers, automatic  
tests are in fact unreliable).

And PEP 754 (and thus fpconst, or some other way for Python code to  
tell if it's running on a minimally functional implementation of IEEE  
754 floats, and if so test for and generate NaNs and infinities)  
should also be there so that the Python-coded unittests can properly  
decide whether to test for compliance.

> time or startup-time checks for the behaviour because 'undefined'  
> also means it need not be consistent, either. The

Yes, but the behavior is not undefined in standard C (1999 standard;  
I don't have access to the 1990 standard)

> best we could do, if we really wanted to return +inf instead of  
> raising OverflowError (which I don't, but don't really care about  
> either), is generate +Infinity in some guaranteed way. I'm sure Tim  
> can come up with a convenient, portable way < 0.9 wink>.

The macro Py_HUGE_VAL seems to be the documented way to do it.  And  
while I'd rather uniformly get infinity from operations producing  
infinity, what I'm really keen to avoid is having one such operation  
raise an exception while another one succeeds.

> But I'd prefer to keep it the way it was: x*x and x**2 don't always  
> do the same thing. Floats have a lot more confusing features like  
> that, such as 10*x - 9*x need not be x. I don't see the added value  
> of trying to make it consistent in just this case, even if it's  
> portable.

There's a huge conceptual gap between, on one side, two values  
produced by "roughly equivalent" expressions being only *ALMOST*  
equal rather than strictly equal, and one of the expressions raising  
an exception while the other one happily proceeds.  The former case  
is reasonably easy to handle -- that's why we have an  
assertAlmostEqual method in unittest.TestCase; the latter can be a  
nightmare.

The same goes for the other bug I recently added to the tracker, the  
""" x != y and [x] == [y] """ one.  Of course, according to this  
"more confusing features" philosophy, I guess it can be considered  
quite OK to leave in Python absurdities like this one, as well.  I  
abhor that whle "slippery slope" philosophy ("there's a tiny  
unavoidable problem in this corner so it's OK to leave a huge gaping  
hole all over the place") but I see no way to resolve such  
philosophical conflict without BDFL pronouncement.  So, I have  
reverted r51525; I now believe it can't be done right (with proper  
unittests) without PEP 754 or something like that, anyway.


Alex