float("nan") in set or as key

[Steven D'Aprano]

On Mon, 30 May 2011 12:53:59 +1000, Chris Angelico wrote:

> Okay, here's a question. The Python 'float' value - is it meant to be "a
> Python representation of an IEEE double-precision floating point value",

Yes.

> or "a Python representation of a real number"? 

No.

Floats are not real numbers. Many fundamental properties of the reals are 
violated by floats, and I'm not talking about "weird" things like NANs 
and INFs, but ordinary numbers:

>>> a, b = 0.1, 0.7
>>> a + b - b == a
False



> For the most part,
> Python's data types are defined by their abstract concepts - a list
> isn't defined as a linked list of pointers, 

Nor is it implemented as a linked list of pointers.


> The sys.float_info struct exposes details of floating point
> representation. In theory, a Python implementation that uses bignum
> floats could quite happily set all those values to extremes and work
> with enormous precision (or could use a REXX-style "numeric digits 100"
> command to change the internal rounding, and automatically update
> sys.float_info). And in that case, there would be no NaN value.

NANs aren't for overflow, that's what INFs are for. Even if you had 
infinite precision floats and could get rid of INFs, you would still need 
NANs.


> The real question is: Would NaN's removal be beneficial? 

No, it would be another step backwards to the bad old days before the 
IEEE standard.




-- 
Steven