Eric Snow ericsnowcurrently at
Thu Apr 28 19:30:29 CEST 2011

On Thu, Apr 28, 2011 at 11:01 AM, Chris Rebert <clp2 at> wrote:

> On Thu, Apr 28, 2011 at 9:21 AM, Eric Snow <ericsnowcurrently at>
> wrote:
> > There's a big discussion going on at python-dev and python-ideas about
> NaN
> > (not-a-number, from IEEE 754).  I haven't really gotten into any
> scientific
> > computing or numeric programming so I have never knowingly dealt with
> NaN.
> >  However, I have read the discussions and several things are not clear:
> > 1. Why is NaN not an exception?  (not "why not change it to one?"
>  Changing
> > it now would probably break stuff.)
> Most things that would produce NaN [e.g. x/0, sqrt(-abs(x))] in
> lower-level languages do produce exceptions in Python. If you
> encounter a NaN in Python, it was probably either explicitly created
> or came from a C extension library. It's basically an abstraction
> leaked through from C/hardware for compatibility.
> > 2. What are the use cases for NaN?  Looks like it gets used a lot as a
> > numeric (float?) object with non-value.
> FWICT, it's useful in lower-level languages (which typically lack
> exceptions and often lack nice ways of returning multiple values from
> a function) as a convenient way of signaling a mathematical error. It
> also lets some calculations continue to limp along (albeit with a NaN
> result) after an error rather than forcing the probably slower
> explicit handling of the error at the time of its occurrence. And it's
> used to represent missing numeric data values, sort of like a
> numerical None/Null: "How much does the truck weigh? NaN (i.e. No
> idea; we haven't put it on the scale yet)."

Thanks Chris.  That's really helpful.  Sounds like NaN is a pretty
overloaded object.  Nick Coghlan brought up in the issue tracker that it is
useful for prototyping algorithms that will be converted to C.  Other than
that, why should Python care?  We have None.  Is it for performance (since
None acts like a number in some ways, but NaN acts like it better)?

Is the problem less with NaN (number object with an undefined value) and
more with the broken reflexivity with regards to equality in general ("x is
x" doesn't imply that "x == x")?  Looks like that situation breaks a number
of different operations in Python, whether or not NaN is involved.

This stuff is way outside my realm of experience so I don't want to wade
into the core lists with these questions, but I want to understand the
issues too...


> Cheers,
> Chris
> --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Python-list mailing list