[Python-Dev] Not-a-Number (was PyObject_RichCompareBool identity shortcut)

Mark Shannon marks at dcs.gla.ac.uk
Thu Apr 28 10:40:20 CEST 2011


Related to the discussion on "Not a Number" can I point out a few things 
that have not be explicitly addressed so far.

The IEEE standard is about hardware and bit patterns, rather than types 
and values so may not be entirely appropriate for high-level language
like Python.

NaN is *not* a number (the clue is in the name).
Python treats it as if it were a number:

 >>> import numbers
 >>> isinstance(nan, numbers.Number)
True

Can be read as "'Not a Number' is a Number" ;)

NaN does not have to be a float or a Decimal.
Perhaps it should have its own class.
The default comparisons will then work as expected for collections.
(No doubt, making NaN a new class will cause a whole new set of problems)

As pointed out by Meyer:
NaN == NaN is False
is no more logical than
NaN != NaN is False

Although both NaN == NaN and NaN != NaN could arguably be a "maybe" 
value, the all important reflexivity (x == x is True)  is effectively 
part of the language.
All collections rely on it and Python wouldn't be much use without 
dicts, tuples and lists.

To summarise:

NaN is required so that floating point operations on arrays and lists
do not raise unwanted exceptions.
NaN is Not a Number (therefore should be neither a float nor a Decimal).
Making it a new class would solve some of the problems discussed,
but would create new problems instead.
Correct behaviour of collections is more important than IEEE conformance
of NaN comparisons.

Mark.


More information about the Python-Dev mailing list