# Es-discuss - several decimal discussions

liorean liorean at gmail.com
Sun Aug 24 16:10:11 PDT 2008

```> On Sun, Aug 24, 2008 at 1:43 PM, liorean <liorean at gmail.com> wrote:
>> And I'd argue that you're wrong there. NaN isn't a single value.

2008/8/25 Mark S. Miller <erights at google.com>:
> Arithmetically, perhaps not. == and === already represent the
> arithmetic semantics of NaN and -0.
>
> Computationally, all NaNs are not observably distinguishable in ES3
> and, AFAIK, in 4/4 browsers. -0 and 0 are observably distinguishable
> in ES3 and in 4/4 browsers.

Not being distinguishable does not mean they are all equivalent. It
just means that the information necessary to distinguish them is not
available.

> Finally, even if some NaNs are observably distinguishable from other
> NaNs (though this is disallowed by ES3 for EcmaScript code), that by
> itself doesn't justify:
>
>    const x = NaN;
>    x === x // yields false
>
> Surely x holds whatever value x holds. How can this value not be the
> same as itself?

As I said, X doesn't contain any specific value, it contains a
symbolic value representing any arbitrary value from an infinite set.
This means that the LHS NaN does not contain the same value as the RHS
NaN, it contains an value that has a likelyhood of 1/Infinity of being
the same as the RHS NaN. Since a NaN does not remember which value it
was converted from, and you're comparing values and not variables,
it's infinitely improbable that they would refer to the same value. So
no, there is no situation where two NaNs should compare as equal
without additional data added that is not present.

>    Object.eq(x, x) // yields true
>
> since the value of x is whatever it is.

Object.eq will be sent two NaN values as arguments, not two x
variables. The likelyhood that they represent the same value is still
1/Infinity.

>> 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.
>
> Then whatever set of arithmetic values is represented by the
> computational value in x, x is a computational value that represents
> that set of arithmetic values.

It does not represent the whole set. It represents a single arbitrary
value from the set, and the NaN has no further data on which of them.
This means that there's no case where you could actually confirm that
two NaNs represent the same value without either:
- having the knowledge of which value was converted to a number,
- or knowing that the two NaNs came from the exact same
variable/property and that the variable/property was not changed in
between.

ECMAScript would provide no data about either to the Object.eq
function, so it could under no circumstance know that they are in fact
representing the same value.

>> 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.
>
> Object.eq() is not an operator of the number system. Between two
> numbers, == and === are already adequate for numeric "equality".

It's an operator on the value system, though. And NaN represents
values, but it can't know which values, and wihtout any further
information about the NaNs you still have to assume they are
infinitely improbable to represent the same value.
--
David "liorean" Andersson
```

More information about the Es-discuss mailing list