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

Andrew Dalke dalke@dalkescientific....
Fri Sep 19 13:39:32 CDT 2008

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  

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

#define NSMALLPOSINTS           257
#define NSMALLNEGINTS           5
/* 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.



More information about the Numpy-discussion mailing list