> 2008/8/24 Brendan Eich <[EMAIL PROTECTED]>: >> Premature generalization without implementation and user experience is >> unwarranted. What would Object.eq(NaN, NaN) do, return true? Never!
2008/8/24 Mark S. Miller <[EMAIL PROTECTED]>: > Object.eq(NaN, NaN) should indeed return true. / snip / > With decimal postponed, we don't need to settle this now. But > JavaScript has no well behaved *equality* operator. As > <http://en.wikipedia.org/wiki/Equivalence_relation> explains, for a > predicate P to be an equivalence relationship (and thereby to define > equivalence classes), it should be > * reflexive: forall x: P(x,x) > * symmetric: forall x,y: P(x,y) implies P(y,x) > * transitive: forall x,y,z: P(x,y) & P(y,z) implies P(x,z) > > However, > * == is not reflexive or transitive. In the Caja project, when we have > occasionally violated our own style and used ==, we've always > regretted it. > * === is not reflexive. Fortunately, there's only one value on which > it isn't, NaN, so code picking off this special case can guard uses of > === which is otherwise well behaved. And I'd argue that you're wrong there. NaN isn't a single value. If you did === on the object that turned into NaN when converted into a number you'd get true, because that's one specific value you're comparing to itself. But NaN represents *any arbitrary value* in the infinite set of values that cannot be converted into numbers, not a *specific value* in that set. Which means that the likelyhood of two NaNs representing the same value approaches zero and is statistically insignificant. In other words, NaN should never equal NaN using any equality operator, unless you build your number system so that NaNs remember what specific value they were converted from and do an object comparison instead of number comparison for those. Which is not the case for ECMAScript. -- David "liorean" Andersson _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
