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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
