On Thu, Jul 9, 2015 at 2:37 AM, Arne Goedeke el@laramies.com wrote:
Violating IEEE without a good reason would introduce other problems, and I'm sure there'll be discussions around the place of exactly why nan has to be unequal to itself. Incidentally, Python's rule about NaN in containers isn't that it compares equal to itself, but that container membership is based on a two-part check of identity and then equality. Among other benefits, that allows automatic optimization of the common case of iterating over the keys and retrieving the values, since the keys will identity-match when you look them up. I think it'd be a good model for Pike to imitate.
The reason for NaN != NaN in IEEE is afaik the one I mentioned. Thanks for the clarification of what python does, I am not much of a python programmer.
I am not so sure about the semantics of id(). It seems to be basically the pointer value of the storage location of the variable. Are floating point values in python passed by reference? Are they objects? This would not work in pike, because floats (as ints) are passed by value.
The semantics of id() in Python are deliberately nonspecific about any precise meaning for that number; in CPython (the most common interpreter) it's the address, but other Pythons use arbitrary sequential numbers, or other schemes. All that matters is:
1) Every object has an identity. 2) If "x is y", then "id(x) == id(y)" 3) If "x is not y", then "id(x) != id(y)", as long as x and y exist concurrently.
And yes, Python floats are objects - everything in Python is an object. In Pike, with floats being value types, the notion of "identity" might have to be expanded to "bit-pattern", but that's slightly less ideal, as it could result in two separately-generated NaNs matching (which otherwise shouldn't happen). But stuffing two different NaNs into a single mapping is going to be pretty rare.
ChrisA