Es-discuss - several decimal discussions

liorean liorean at
Sun Aug 24 13:43:29 PDT 2008

> 2008/8/24 Brendan Eich <brendan at>:
>> 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 <erights at>:
> 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
> <> 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

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

More information about the Es-discuss mailing list