Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #6614

Re: float("nan") in set or as key

Show all headers | View raw

On Mon, May 30, 2011 at 12:17 PM, Carl Banks <pavlovevidence@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

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: float("nan") in set or as key Carl Banks <pavlovevidence@gmail.com> - 2011-05-29 19:17 -0700
  Re: float("nan") in set or as key Chris Angelico <rosuav@gmail.com> - 2011-05-30 12:53 +1000
    Re: float("nan") in set or as key rusi <rustompmody@gmail.com> - 2011-05-29 20:08 -0700
    Re: float("nan") in set or as key Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-30 04:22 +0000

csiph-web