According to MDN,
NaN is a property of the global object. In other words, it is a variable in global scope.
The initial value of NaN is Not-A-N...
For further actions, you may consider blocking this person and/or reporting abuse
I have not really used NaN directly in years, I wonder why this is. Oh this reminds me, I found a method I either forgot about or had completely missed.
Number.isInterger. ✨ learn a new thing every day.Just to clear things up,
NaNis just a specially formatted number defined by the IEEE 754 standard, hence having thetypeofnumber.NaNsimply represents a "floating-point arithmetic exception", but it is still laid out in memory as a floating-point number.Let's be clear that NaN is not a number in IEEE. :)
It is a value that is used as a code to indicate that a floating point exception has occurred and the value does not represent a number.
But in memory, it is still stored as a floating-point number, hence the
typeofnumber. Although it is not exactly a correct description, it is kinda correct from the viewpoint of low-level memory. The bits of the "number" are just specially formatted to indicate an arithmetic exception.I just meant to clarify that
typeof NaN === 'number'isn't as unfounded as it first seems. 😉NaN is the numerical representation of a value which was tried to be cases as a number, evaluated as an expression or directly assign a value of NaN. So it's time would be a "Number'. But wouldn't make sense if 2 NaN is equal.
NaN isn't a numerical representation, because it isn't represented with numerals. :)
Let's call it, a tried and failed numerical representation 😁 just for the fun of it😬
Well, I don't think this quite follows.
Javascript could have specified that typeof NaN is not 'number' -- it isn't required because of any IEEE representation -- it could have just as easily decided that NaN is its own kind of thing, and said that typeof NaN === 'NaN'.
This is a kind of arbitrary decision, but you can think about the advantages and disadvantages of these decisions.
Personally, I think that it makes sense for typeof NaN to be 'number' because it is produced by the same kind of operations that produce numbers -- so it's something that you expect to pass through the same interfaces.
That is, things that expect 'number' type things should also expect NaNs.
But this isn't determined by IEEE or anything else really -- it's just something that the
people who developed Javascript decided because it was felt to be useful to most people most of the time.
Great thought process! But typeof give the primitive types and they might have thought it's not worth having a separate type for a value that is used very less!
I agree.
NaNis really just an unfortunate (but equally appropriate) acronym for something that works like a number.Hi Suren, nice article! :-)
After reading your post I decided to share my thoughts on the NaN special value here in the comments, but then I noticed that comment started to get bigger so I decided to write a post 😅
Here's the link to my post. I hope it helps 🙂👍
¡Keep up the good work!
Good one, Diego✨
I discovered this week that NaN is truthy. A bunch of state values were showing undefined in a React app. However, it used server side rendering to initialize the state, and they started as NaN, causing a bunch of things to flash from one value to the next when the state updated. That was a fun two hours.
I would be more careful when dealing with numbers in state of numbers now😁
It's probably worth noting that NaN === NaN is false, which is why there's isNaN to detect it.
True!
Oh wow, I just realized after reading this, that I have never really looked at what really is NaN.😅
Glad it helped you, Tanvesh! Now you know and that's great 😉
Great, thanks