[Numpy-discussion] np.nan and ``is``

[Andrew Dalke]

On Sep 19, 2008, at 7:52 PM, Christopher Barker wrote:
> I don't know the interning rules, but I do know that you should never
> count on them, then may not be consistent between implementations, or
> even different runs.

There are a few things that Python-the-language guarantees are singleton
objects which can be compared correctly with "is".  Those are:

   True, False, None

Otherwise there is no guarantee that two objects of a given type
which are "equal" in some sense of the word, are actually the same  
object.

As Chris pointed out, the C implementation does (as a performance
matter) have additional singletons.  For example, the integers between
-5 to 257 are also singletons


#ifndef NSMALLPOSINTS
#define NSMALLPOSINTS           257
#endif
#ifndef NSMALLNEGINTS
#define NSMALLNEGINTS           5
#endif
/* References to small integers are saved in this array so that they
    can be shared.
    The integers that are saved are those in the range
    -NSMALLNEGINTS (inclusive) to NSMALLPOSINTS (not inclusive).
*/
static PyIntObject *small_ints[NSMALLNEGINTS + NSMALLPOSINTS];


This used to be -1 to 100 but some testing showed it was better
to extend the range somewhat.

There was also some performance testing about special-casing 0.0
and +/- 1.0 but I think it showed the results weren't worthwhile.


So, back to NaN.  There's no guarantee NaN is a singleton
object, so testing with "is" almost certainly is wrong.
In fact, at the bit-level there are multiple NaNs.  A
NaN (according to Wikipedia) fits the following bit pattern.

   NaN: x11111111axxxxxxxxxxxxxxxxxxxxxx. x = undefined. If a = 1,

   it is a quiet NaN, otherwise it is a signalling NaN.


So  11111111111111111111111111111111
and 11111111111111111111111111111110
and 11111111111111111111110000000000

are all NaN values.

>

				Andrew
				dalke at dalkescientific.com