float("nan") in set or as key

[rusi]

On May 30, 7:53 am, Chris Angelico <ros... at gmail.com> wrote:
> On Mon, May 30, 2011 at 12:17 PM, Carl Banks <pavlovevide... at gmail.com> wrote:
> > If I were designing a new floating-point standard for hardware, I would consider getting rid of NaN.  However, with the floating point standard that exists, that almost all floating point hardware mostly conforms to, there are certain bit pattern that mean NaN.
>
> > Python could refuse to construct float() objects out of NaN (I doubt it would even be a major performance penalty), but there's reasons why you wouldn't, the main one being to interface with other code that does use NaN.  It's better, then, to recognize the NaN bit patterns and do something reasonable when trying to operate on it.
>
> 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", or "a Python representation of a real number"? 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, it's defined as an
> ordered collection of objects. Python 3 removes the distinction
> between 'int' and 'long', where 'int' is <2**32 and 'long' isn't, so
> now a Py3 integer is... any integer.
>
> 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.
>
> If Python is interfacing with some other code that uses NaN, that code
> won't be using Python 'float' objects - it'll be using IEEE binary
> format, probably. So all it would need to entail is a special return
> value from an IEEE Binary to Python Float converter function (maybe
> have it return None), and NaN is no longer a part of Python.
>
> The real question is: Would NaN's removal be beneficial? And if so,
> would it be worth the effort?
>
> Chris Angelico

nan in floating point is like null in databases
It may be worthwhile to have a look at what choices SQL has made
http://en.wikipedia.org/wiki/Null_%28SQL%29