On Thu, Jul 9, 2015 at 2:09 AM, Arne Goedeke <e...@laramies.com> wrote: >> Of course all this is nothing new. Python afaik tries to treat NaN in >> containers as if it compared equal to itself. Is that the best one can >> do? > > > What about the following radical proposal: Define Math.nan == Math.nan to > be true. It would immediately fix all the inconsistencies with container > types. The only purpose of NaN != NaN in the ieee standard seemed to > have been to make it simple to detect NaN without having isnan(). > > Would this be a compatibility problem? Do people detect Math.nan using x != > x?
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. ChrisA
