[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