On Thu, Jul 9, 2015 at 2:37 AM, Arne Goedeke <e...@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
