[Python-Dev] Not-a-Number (was PyObject_RichCompareBool identity shortcut)

Steven D'Aprano steve at pearwood.info
Fri Apr 29 02:31:10 CEST 2011


Terry Reedy wrote:

> I think the committee goofed -- badly. Statisticians used missing value 
> indicators long before the committee existed. They has no problem 
> thinking that the indicator, as an object, equaled itself. So one could 
> write (and I often did through the 1980s) the equivalent of
> 
> for i,x in enumerate(datavec):
>   if x == XMIS: # singleton missing value indicator for BMDP
>     datavec[i] = default

But NANs aren't missing values (although some people use them as such, 
that can be considered abuse of the concept).

R distinguishes NANs from missing values: they have a built-in value 
NaN, and a separate built-in value NA which is the canonical missing 
value. R also treats comparisons of both special values as a missing value:

 > NA == NA
[1] NA
 > NaN == NaN
[1] NA

including reflexivity:

 > x = NA
 > x == x
[1] NA

which strikes me as the worst of both worlds, guaranteed to annoy those 
who want the IEEE behaviour where NANs compare unequal, those like Terry 
who expect missing values to compare equal to other missing values, and 
those who want reflexivity to be treated as an invariant no matter what.



>> NaN is Not a Number (therefore should be neither a float nor a Decimal).
>> Making it a new class would solve some of the problems discussed,
>> but would create new problems instead.
> 
> Agreed, if we were starting fresh.

I don't see that making NANs a separate class would make any practical 
difference what-so-ever, but the point is moot since we're not starting 
fresh :)


>> Correct behaviour of collections is more important than IEEE conformance
>> of NaN comparisons.
> 
> Also agreed.

To be pedantic, the IEEE standard doesn't have anything to say about 
comparisons of lists of floats that might contain NANs. Given the 
current *documented* behaviour that list equality is based on object 
equality, the actual behaviour is surprising, but I don't think there is 
anything wrong with the idea of containers assuming that their elements 
are reflexive.





-- 
Steven


More information about the Python-Dev mailing list