[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