Steven D'Aprano writes: > I don't think so. Floating point == represents *numeric* equality,
There is no such thing as floating point == in Python. You can apply == to two floating point numbers, but == (at the language level) handles any two numbers, as well as pairs of things that aren't numbers in the Python language. So it's a design decision to include NaNs at all, and another design decision to follow IEEE in giving them behavior that violates the definition of equivalence relation for ==. > In an early post, you suggested that NANs don't have a value, or that > they have a value which is not a value. I don't think that's a good way > to look at it. I think the obvious way to think of it is that NAN's > value is Not A Number, exactly like it says on the box. Now, if > something is not a number, obviously you cannot compare it numerically: And if Python can't do something you ask it to do, it raises an exception. Why should this be different? Obviously, it's question of expedience. > I'm not sure what you're referring to here. Is it that containers such > as lists and dicts are permitted to optimize equality tests with > identity tests for speed? No, when I say I'm fuzzy I'm referring to the fact that although I understand the logical rationale for IEEE 754 NaN behavior, I don't really understand the ins and outs well enough to judge for myself whether it's a good idea for Python to follow that model and turn == into something that is not an equivalence relation. I'm not going to argue for a change, I just want to know where I stand. > Basically, and I realise that many people disagree with their decision > (notably Bertrand Meyer of Eiffel fame, and our own Mark > Dickenson), Indeed. So "it's the standard" does not mean there is a consensus of experts. I'm willing to delegate to a consensus of expert opinion, but not when some prominent local expert(s) disagree -- then I'd like to understand well enough to come to my own conclusions. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com