[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