On May 30, 7:53 am, Chris Angelico <ros...@gmail.com> wrote: > On Mon, May 30, 2011 at 12:17 PM, Carl Banks <pavlovevide...@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 -- http://mail.python.org/mailman/listinfo/python-list
