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.
But in memory, it is still stored as a floating-point number, hence the typeof number.
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!
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.