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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
