Nick Maclaren wrote:

...

...

I really do mean that quite a lot of floating-point bells and whistles are non-transitive.

Martin v. Löwis wrote:

...

If so, they just shouldn't use the equal operator (==). == ought to be transitive. It should be consistent with has().

Nick Maclaren wrote:

Fine. A very valid viewpoint. Would you like to explain that to the IEEE 754 people?

When Decimal was being argued, Tim pointed out that the standard requires certain operations, but doesn't require specific spelling shortcuts. If you managed to do (and document) it right, people would be grateful for methods like a.exactly(b) a.close_enough(b) a.same_expected_value(b) but that doesn't mean any of them should be used when testing a==b (In Lisp, you typically can specify which equality predicate a hashtable should use on pairs of keys; in python, you only specify which it should use on objects of your class, and if the other object in the comparison disagrees, you're out of luck.)

Strictly, it is only the reflexive property that IEEE 754 and the Decimal module lack. Yes, A == A is False, if A is a NaN.

Therefore NaNs should never be used (in python) as dictionary keys. Therefore, they should be unhashable. Also note that PyObject_RichCompareBool (from Objects/object.c) assumes the reflexive property, and if you try to violate it, you will get occasional surprises.

We already have the situation where A == B == 0, but where 'C op A' != 'C op B' != 'C op 0'. Both where op is a built-in operator and where 'C op' is a standard library function.

That's fine; it just means that numeric equality may not be the strongest possible equivalence. hash in particular just happens to be defined in terms of ==, however == is determined. -jJ