On Mon, Oct 8, 2012 at 11:14 PM, Alexander Belopolsky email@example.com wrote:
On Mon, Oct 8, 2012 at 10:09 PM, Guido van Rossum firstname.lastname@example.org wrote:
Such a rationale exists in my mind. Since floats are immutable, an implementation may or may not intern certain float values (just as certain string and int values are interned but others are not).
This is an interesting argument, but I don't quite understand it. Are you suggesting that some valid Python implementation may inter NaNs? Wouldn't that require that all NaNs are equal?
Sorry, it seems I got this part slightly wrong. Forget interning. The argument goes the other way: If you *do* compute x and y exactly the same way, and if they don't return the same object, and if they both return NaN, the rules for comparing NaN apply, and the values must compare unequal. So if you compute them exactly the same way but somehow you do return the same object, that shouldn't suddenly make them compare equal.
Therefore, the fact that "x is y" says nothing about whether the computations that produced x and y had anything to do with each other.
This is not true for mutable objects: if I have two lists, computed separately, and find they are the same object, the computations that produced them must have communicated somehow, or the same list was passed in to each computations.
So, since two computations might return the same object without having followed the same computational path, in another implementation the exact same computation might not return the same object, and so the == comparison should produce the same value in either case
True, but this logic does not dictate what this values should be.
-- in particular, if x and y are both NaN, all 6 comparisons on them should return False (given that in general comparing two NaNs returns False regardless of the operator used).
Except for operator compareQuietUnordered() which is missing in Python. Note that IEEE 754 also defines totalOrder() operation which is more or less lexicographical ordering of bit patterns. A hypothetical language could map its 6 comparisons to totalOrder() and still claim IEEE 754 conformity as long as it implements the other 22 comparison predicates somehow.
Yes, but that's not the choice Python made, so it's irrelevant. (Unless you now *do* want to change the language, despite stating several times that you were just asking for explanations. :-)
The reason for invoking IEEE 754 here is that without it, Python might well have grown a language-wide rule stating that an object should *always* compare equal to itself, as there would have been no significant counterexamples.
Why would it be a bad thing? Isn't this rule what Bertrand Meyer calls one of the pillars of civilization?
I spent a week with Bertrand recently. He is prone to exaggeration. :-)
It looks like you give a circular argument. Python cannot have a rule that x is y implies x == y because that would preclude implementing float.__eq__ as IEEE 754 equality comparison and we implement float.__eq__ as IEEE 754 equality comparison in order to provide a significant counterexample to x is y implies x == y rule. I am not sure how interning comes into play here, so I must have missed something.
No, that's not what I meant -- maybe my turn of phrase "invoking IEEE" was confusing. The first part is what I meant: "Python cannot have a rule that x is y implies x == y because that would preclude implementing float.__eq__ as IEEE 754 equality comparison." The second half should be: "And we have already (independently from all this) decided that we want to implement float.__eq__ as IEEE 754 equality comparison." I'm sure a logician could rearrange the words a bit and make it look more logical.