Hacker News Reader

Comment by meastham | Hacker News Reader

NaN === NaN is guaranteed to be false by IEEE 754. Hardly a wtf.

Actually most of these posts seem to be the author misunderstanding floating point numbers. Perhaps he should learn what he's doing before he blames the language.

View on HN

Yup; Number.MIN_VALUE has the minimum possible mantissa and exponent, for example. If you want the most negative possible number, you don't need a separate constant, you can just use -(Number.MAX_VALUE), as 754 reals are signed-magnitude.

This suggests that you don't actually know what the === operator is. To summarize:

== - 'values are equal' - in this case, are these two numbers equal? The IEEE spec would say no. I agree!

=== - 'both sides are exactly the same' - or, in more technical terms, are both the values and types of each argument exactly identical. In this case, the answer is yes, absolutely. === is not a numerical comparison and should not be.

=== means value and type are equal. In this case, the types are equal, but the values are not. I'd argue that NaN === NaN being true would imply a broken implementation of IEEE 754, and the designers of JS seem to agree with me.

What benefit is created by having a hierarchy of comparison operators in which there is no actual way to compare two numbers for semantic (not numeric) equivalence?

If (NaN == NaN) == false, and (NaN === NaN) == false, how would you implement an isNaN() function? If your answer is 'depend on the VM', I find that a bit strange.

typeof(NaN) should still be 'number', which would identify it uniquely. The irony of the value "Not a Number" having type "Number" is not lost on me, however.

function isNaN(x) { return x != x; };

new String("foo") === new String("foo") is false. === does not mean value and type are equal, it means that the left is the same object as on the right OR that both the left and right are primitives with the same value.

The behavior there is a result of the 'new' operator. typeof new String("foo") is specified to be "object", and it is extensible (String("foo") is not). Both == and === on two object-types return true if both refer to the same thing. More generally, when two types are the same, == has the same behavior as ===.

> In this case, the answer is yes, absolutely.

No, it isn't, absolutely.

`===` means that javascript does a normal equality test, whether it be string comparison or numerical comparison, but without any type conversion. It means that while `"3" == 3` is `true` when you execute `"3" === 3"` it is false.

Given two `NaN`s, it would see they're both floats, do a floating point comparison, and return `false`. As it should.

"== - 'values are equal' - in this case, are these two numbers equal? The IEEE spec would say no." "=== - ...are both the values and types..."

If the values are not equal, how can both the values and types be?

Looking at the ECMAScript 5 standard even if you take out the explicit handling of NaN in the === (Strict Equality) definition it should still evaluate to false since the next subrule compares the numeric value.

4.If Type(x) is Number, then a.If x is NaN, return false. b.If y is NaN, return false. c.If x is the same Number value as y, return true.

Reply on news.ycombinator.com