This question already has answers here:
What is the rationale for all comparisons returning false for IEEE754 NaN values?
(12 answers)
Closed 6 years ago.
Why does NaN === NaN return false in Javascript?
> undefined === undefined
true
> NaN === NaN
false
> a = NaN
NaN
> a === a
false
On the documentation page I see this:
Testing against NaN
Equality operator (== and ===) cannot be used to test a value against NaN. Use isNaN instead.
Is there any reference that answers to the question? It would be welcome.
Strict answer: Because the JS spec says so:
If Type(x) is Number, then
If x is NaN, return false.
If y is NaN, return false.
Useful answer: The IEEE 754 spec for floating-point numbers (which is used by all languages for floating-point) says that NaNs are never equal.
This behaviour is specified by the IEEE-754 standard (which the JavaScript spec follows in this respect).
For an extended discussion, see What is the rationale for all comparisons returning false for IEEE754 NaN values?
Although either side of NaN===NaN contains the same value and their type is Number but they are not same. According to ECMA-262, either side of == or === contains NaN then it will result false value.
you may find a details rules in here-
http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3
Related
This question already has answers here:
What is the rationale for all comparisons returning false for IEEE754 NaN values?
(12 answers)
Closed 5 years ago.
Why does NaN === NaN return false in Javascript?
> undefined === undefined
true
> NaN === NaN
false
> a = NaN
NaN
> a === a
false
On the documentation page I see this:
Testing against NaN
Equality operator (== and ===) cannot be used to test a value against NaN. Use isNaN instead.
Is there any reference that answers to the question? It would be welcome.
Strict answer: Because the JS spec says so:
If Type(x) is Number, then
If x is NaN, return false.
If y is NaN, return false.
Useful answer: The IEEE 754 spec for floating-point numbers (which is used by all languages for floating-point) says that NaNs are never equal.
This behaviour is specified by the IEEE-754 standard (which the JavaScript spec follows in this respect).
For an extended discussion, see What is the rationale for all comparisons returning false for IEEE754 NaN values?
Although either side of NaN===NaN contains the same value and their type is Number but they are not same. According to ECMA-262, either side of == or === contains NaN then it will result false value.
you may find a details rules in here-
http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3
This question already has answers here:
Why does typeof NaN return 'number'?
(21 answers)
Closed 3 years ago.
In Javascript, the value 0/0 returns NaN. But why does the typeof operator return this value as a Number type? I was expecting typeof to also return NaN.
let value = 0/0
console.log(value, typeof(value))
The console returns: NaN, "Number"
Because NAN is a number!! lol gotta love JS!
typeof(NaN)
//= number
A good description from: https://javascriptrefined.io/nan-and-typeof-36cd6e2a4e43
The ECMAScript standard states that Numbers should be IEEE-754 floating point data. This includes Infinity, -Infinity, and also NaN.
By definition, NaN is the return value from operations which have an undefined numerical result. Hence why, in JavaScript, aside from being part of the global object, it is also part of the Number object: Number.NaN. It is still a numeric data type, but it is undefined as a real number.
This question already has answers here:
Why does [NaN].includes(NaN) return true in JavaScript?
(5 answers)
Closed 24 days ago.
I'm learning about includes() feature, and I found this code
[NaN].includes(NaN) //True
But
NaN === NaN // False
Why this is posible?
Using equality NaN === NaN and using includes [NaN].includes(NaN) are basically asking two different questions:
Equality - are this things that have the same name are actually equal?
NaN is an amorphic entity, which describes the concept of not being a numeric value, and doesn't actually have a value you can compare. Equality uses the Strict Equality Comparison, and defines that a comparison x === y with NaN on any side of the equation is always false:
a. If x is NaN, return false.
b. If y is NaN, return false.
Includes - do I have something with that "name" in the array?
However, to search for a NaN in an array, and to keep the to Array#includes signature of passing only one param, and not a callback, we need a way to "name" what we are searching for. To make that possible, ccording to the Array#includes definition in the ECMAScript 2016 (ECMA-262) docs:
The includes method intentionally differs from the similar indexOf
method in two ways. First, it uses the SameValueZero algorithm,
instead of Strict Equality Comparison, allowing it to detect NaN
array elements. Second, it does not skip missing array elements,
instead treating them as undefined.
The definition of SameValueZero(x, y) states that when comparing:
If x is NaN and y is NaN, return true.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/isNaN
Unlike all other possible values in JavaScript, it is not possible to rely on the equality operators (== and ===) to determine whether a value is NaN or not, because both NaN == NaN and NaN === NaN evaluate to false. Hence, the necessity of an isNaN function.
[ NaN ].includes(NaN) what this does is to check if NaN is in the [ ].
NaN === NaN and NaN == NaN will still return the same value which is false. What you just have to know is that the includes methods checks if a value is the array it is been called on. Behind the hood i think the includes Array method does it's checks using typeof()
typeof(NaN) // number
[ NaN ].includes(NaN) // true
typeof("1") // string
[ 1 ].includes("1") // false
typeof(1) // number
[ 1 ].includes(1) // true
this is according to the SameValueZero Algorithm that the includes method uses. Internally it checks the type of the value
This question already has answers here:
Object.is vs ===
(6 answers)
Closed 5 years ago.
We know what the difference between == and === is - basically, === prevents Javascript engine to convert one of the parameter for making both parameters of the same type. But now, in ES6, came a new operator - Object.is which is a bit confusing (or maybe === is now confusing..)
From Mozila website (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Equality_comparisons_and_sameness) we can see the difference:
Sameness Comparisons:
x y == === Object.is
+0 -0 true true false
NaN NaN false false true
So, for me, looks like Object.is is even more strict in comparing parameters, if so, question raises - how unstrict was === (called "Strict Equality") :)
From the article you linked:
When to use Object.is versus triple equals
Aside from the way it treats NaN, generally, the only time Object.is's special behavior towards zeros is likely to be of interest is in the pursuit of certain meta-programming schemes, especially regarding property descriptors when it is desirable for your work to mirror some of the characteristics of Object.defineProperty. If your use case does not require this, it is suggested to avoid Object.is and use === instead. Even if your requirements involve having comparisons between two NaN values evaluate to true, generally it is easier to special-case the NaN checks (using the isNaN method available from previous versions of ECMAScript) than it is to work out how surrounding computations might affect the sign of any zeros you encounter in your comparison.
Via MDN:
This is also not the same as being equal according to the === operator. The === operator (and the == operator as well) treats the number values -0 and +0 as equal and treats Number.NaN as not equal to NaN.
This question already has answers here:
What is the rationale for all comparisons returning false for IEEE754 NaN values?
(12 answers)
Closed 8 years ago.
I am wondering why undefined == undefined but NaN != NaN.
Because that's how it is defined in both the Abstract Equality Comparison Algorithm, and the Strict Equality Comparison Algorithm.
If either operand to == or === is NaN, it returns false.
Abstract
If Type(x) is Number, then
If x is NaN, return false.
If y is NaN, return false.
If x is the same Number value as y, return true.
If x is +0 and y is −0, return true.
If x is −0 and y is +0, return true.
Return false.
EDIT: The motivation for the unequal comparison as noted by #CMS is compliance with the IEEE 754 standard.
From the Wikipedia link provided in the comment below:
...The normal comparison operations however treat NaNs as unordered and compare −0 and +0 as equal. The totalOrder predicate will order these cases, and it also distinguishes between different representations of NaNs and between the same decimal floating point number encoded in different ways.
Because Math.sqrt(-5) !== Math.sqrt(-6).
Not sure why it is like this, but in order to check if a certain statement or variable is a NaN, you should use the isNaN method
I would assume because the IEEE standard allows for more than one representation of NaN. Not all NaNs are equal to each other...
The reasoning is that the creators wanted x == x returning false to mean that x is NaN, so NaN == NaN has to return false to be consistent.