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 -- http://mail.python.org/mailman/listinfo/python-list
