We found some strange behavior of the handling of "nan"
if "nan" is used in if-statements.

We use Python 2.2 (python2-2.2.2-11.7.3.src.rpm).
In the following i show the results of the
"experiments" with "nan", "inf" and usual floats:


$ python
Python 2.2.2 (#1, Jan 30 2003, 21:26:22) 
[GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-112)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> a=float(1.2345)
>>> b=float("inf")
>>> c=float("nan")
>>> if a==b:
...  print "equal"
... 
>>> if a==c:
...  print "equal"
... 
equal
>>> if b==c:
...  print "equal"
... 
equal


Bernhard Seiwald seiwald@itp.tugraz.at

Logged In: YES 
user_id=31435

Sorry, but all behavior in the presence of NaNs and infinities 
and signed zeroes is a platform- and release- dependent 
accident.  Even that float("inf") didn't raise an exception for 
you is an accident (e.g., in Python 2.2.2 on Windows, it 
does raise an exception).

I've added this to PEP 42's "non-accidental 754 support" 
feature request; you may also be interested in PEP 754 
(support for 754 special values).  Python has no 754 story 
now.  If you want it to have one, consider volunteering work 
toward that end.

For the benefit of those who stumble here through Google, here's a
workaround I've discovered for NaN testing. This is BAD:

value == float('NaN')

But this seems to work ok:

str(value) == str(float('NaN'))

Reclassifying as out of date.  NaN handling in Python 2.6 and later is non-accidental.

(and math.isnan is the recommended way to test for a nan).