[Python-ideas] Why is nan != nan?
Marcin 'Qrczak' Kowalczyk
qrczak at knm.org.pl
Sat Mar 27 11:21:17 CET 2010
2010/3/26 Greg Ewing <greg.ewing at canterbury.ac.nz>:
> Eiffel even seems to extend this to conversions, so that
> if you convert an int to a float, the resulting float should
> compare equal to the original int, even if some precision
> was lost in the conversion.
Such equality is not transitive (unless 1000000000 and 1000000001 are
equal as ints which would be nonsense).
The original problem with NaN is a consequence of an unfortunate
decision to unify numeric equality with object equivalence. If they
were distinguished, their behavior would be obvious:
NaN != NaN
NaN eq NaN
0.0 == -0.0
0.0 ne -0.0
42 == 42.0
42 ne 42.0
Hash tables would use object equivalence of course.
If you have a type for a time which includes the local time and the
time zone, and < > <= >= compare which time is earlier, then numeric
== should be true for times denoting the same time through different
time zones, but they should not be equivalent.
Lisp and Scheme distinguish these relations.
--
Marcin Kowalczyk
More information about the Python-ideas
mailing list