What is the NaN for?

Who has invented it?

NaN is not an invention of JavaScript. It is part of the IEEE-754 specification that defines how to represent real numbers in binary. All current implementations of real numbers used by different programming languages ​​are based on this specification, such as types float(corresponding to IEEE-754 single-precision that uses 32 bits to represent reals) and double(corresponding to IEEE-754 single-precision). extended precision, which uses 64 bits to represent the reals) of C. Not only C, but practically every current language uses this standard, because the hardware itself (the CPU's math processor) uses it. In the case of JavaScript, moreover, the language lacks the integer type (int) so any JavaScript number is actually a double. We'll come back to JavaScript later. For now let's focus on IEEE-754.

Leaving aside the problems of range and precision, which would be for another question and which deals with how it is possible to put all the reals (which are infinite, in fact an infinity of higher order than the infinity of the natural ones) in only 32 or 64 bits ( spoiler , you can't :-), and that's why weird things happen ) there is the additional problem that certain mathematical operations are defined for a subset of the reals, but not for all. I will focus on this problem here.

Why was it necessary?

The division, for example. It is possible to divide any two reals and the result will be another real, except in the case that the divisor is zero. In that case, the mathematical convention is adopted (for which there are good reasons I won't go into) that the result is "infinity" (or negative infinity if the numerator was negative).

"infinity" is not a real number. It is a concept. There is no real equal to infinity. However, if we have a "division" operation whose return type is floator double, then we must provide one (32 or 64) bit combination to represent "infinity" (and one for "negative infinity"). The IEEE-754 standard provides for this.

Infinity is not enough. There are other mathematical operations that have no definite result, and for which it makes no sense to say that "outputs infinity". For example, the square roots of any negative number have no result in real numbers. The same goes for the logarithm of zero, or any negative. Or with the arc sine of any number that is not between 0 and 1, etc. There are many examples of functions that are defined for only a subset of the reals. Trying to evaluate them on an element that is not in that subset should be treated as an error.

In languages ​​that support exceptions, like JavaScript, Python, Java, etc. use could be made of this mechanism to signal the problem. In fact, Python for example does this, and when trying to calculate math.log(-1)the exception is obtained ValueError. However, in other more primitive languages ​​such as C or assembly, in which there are no exceptions, it is necessary to provide a certain combination of bits, similar to the case of infinity seen above, which represents that the operation is not valid. Or that "the result is not a real". Not a Number . NaN.

IEEE-754 provides for this as well, and has a code (in fact a large number of them) to encode the "Not a number" concept. The CPU's math processor is the mechanism it uses, and what it returns as a result of illegal operations. C functions can also return that value (because it is a valid element of type floato double). Higher-level languages ​​can choose to catch this result and raise an exception (as Python does), or "let it pass" and return NaN (as JavaScript does).

What binary representation does it have?

The binary code that represents NaN in IEEE-754 single precision (32 bits) is x11111111xxxxxxxxxxxxxxxxxxxxxxxx, with each x being a bit that can be 1 or 0, except that the last 23 x cannot all be 0 (because in that case it would be representing infinity, the first bit being the sign). As we can see, the standard does not define a unique code for NaN, but in fact we have 2^(24)-2 possible representations. However, they are all considered equivalent, that is, conceptually there is "a single NaN" that can be represented in many ways.

In the case of double precision IEEE-754, there are even more possibilities, since in this format NaN is any bit pattern of the type x11111111111xxxx...xxx in which we have a first bit that can be 1 or 0 , another eleven bits that must be 1, and another 52 bits that can take any value as long as they are not all 0. With this pattern, 2^(53)-2 different codes can be generated.

Why so many different codes to represent NaN? The truth is that I don't know. Only one would do. My guess is that the designers of this standard couldn't find any other way to take advantage of the remaining 2^(24)-1 [or 2^(53)-1 in double precision] codes.

Edition . As @JoseManuelRamos mentions in a comment, the reason for that number of "reserved" codes stems from the fact that all IEEE-754 codes that have all 1's in the exponent field, are reserved for special values ​​(two of them would be infinity and minus infinity , and the rest would be NaN.

But the next question is then why this "waste"? Couldn't the bits of the mantissa in all those cases be somehow exploited to encode something else? The answer, which I originally didn't know but later I found out, is that they can be used , to put in them what is called the NaN payload . In theory, if an operation returns NaN, the binary code representing it will have all 1s in the exponent part and some other code (non-all zeros) in the mantissa part, and what that code means depends on the application, which you can use it as you want. For example, it might contain information about what operation was being done when the error occurred. There is room for many codes!

The problem is that its use is not standardized, and therefore in practice it cannot be used reliably for anything, although it is an available option to implement creative ideas.

It seems that some implementations of the JavaScript interpreter used it to save a few bits on the implementation of the data model, through a trick (almost a hack ) they called NaN boxing . The idea was to use those 52 bits of mantissa available in a doubleto hold a 32-bit pointer and a 20-bit tag . The tag would indicate what type the pointer points to (number, string, list, object, etc.) Also, if the exponent is not "all 1", it would be a doublenormal, so in the same "underlying" type ( double, 64-bit) many different types can be implemented.

Why NaN != NaN?

Basically to avoid logic errors. If you have that f(x) == f(y)you might think that x == y. This is correct for many functions. For example, the square root. If Math.sqrt(a) == Math.sqrt(b)one could deduce that then a == b. Indeed, if for example Math.sqrt(a) == 5and the same for Math.sqrt(b), we can deduce that they aare bworth 25.

But what if a=-1while b=-4? In that case as much Math.sqrt(a)as Math.sqrt(b) will result in NaN. If we accept that NaN == NaN, we could reach the erroneous conclusion that a==b. Therefore by definition NaN it is always different from NaN(even if "below" are represented with the same binary code).

In fact, once an operation has produced NaN, any other operation it uses NaNas an argument should NaNreturn in turn. If we were to allow NaN == NaNthat would imply that it NaN/NaNshould be 1, which would make it impossible to "propagate" the erroneous result between operations.

rarities

NaNis a value of type float(o double) as already stated. Since JavaScript is the only numeric type it has, which it generically calls "number", it turns out to NaNbe a valid "number". Which is not without its grace.

>>> typeof(NaN)
"number"

JavaScript uses NaNin contexts beyond those intended by the standard. For example, if you try to divide a number by a string, you will get an error, but of a different nature than the one in Math.log(-1). In the case of 1/"cadena"is a typing error. Not even the return type would be defined in this case. JavaScript decides that the result is of type "number", and since it can't give it a value, it gives it the value NaN.

>>> typeof(1/"cadena")
"number"
>>> 1/"cadena"
NaN

Finally, it could be thought that the same reasons put forward to defend that NaN != NaNwould apply to "infinity", since if a/0 == b/0that does not imply a == b, but instead the IEEE-754 standard does not consider it that way. We can check it with JavaScript:

>>> Infinity == Infinity
true

NaN or exception?

It could be argued that an attempt to compute Math.log(-1)is an error that should throw an exception. Some languages ​​do this by detecting that a result is NaN. However, the engineers who designed the IEEE-754 standard preferred to return a "special value" rather than generate a hardware exception, since that simplified the implementation at that time.

I also insist on the fact that, as the behavior of is defined NaN, once an operation has produced NaN, any other operation that uses the previous result will continue to result in NaN. Specifically NaN - NaN = NaN(another argument why NaN!=NaN, since the comparison is usually implemented at the hardware level with a subtraction). This "viral" behavior NaNis very reminiscent of how an exception propagates up from the function that raised it to the functions that called it.

Also there may be cases where returning NaNis more useful than throwing an exception. A typical example is searching for zeros in a function, by a method similar to Newton 's . The problem is, given a function, f(x)find a value of xfor which f(x)is zero. Newton's method and others like it are based on trying a couple of values ​​of xand if they f(x)are non-zero, using the result to better "tune" the next try. Without going into more detail, we can see that if f(x)it is not defined for all possible it xmay be the case that we try a xfor which it is not defined. Throwing an exception would abort the method, while returningNaNit would allow him to go ahead and try another x. But in reality this justification seems flimsy to me. The same could be achieved (I think) by catching the exception and trying another x.

The true reason for the existence of NaNmust be sought in its historical roots. At the time it was designed, this solution was much easier to implement with minimal modification to existing compilers and languages. For example, C, the most important language then (and perhaps even now) has no exceptions, and instead bases its error handling on functions returning "special values" to indicate that there was an error (-1 if the type returned is int, NULLif return type is pointer, and NaNif return type is floator double).

JavaScript seems to be the heir to this current, since NaNit is not the only case in which this language has chosen to return a "special" value instead of generating an exception. For example, accessing an array outside its bounds (which in other languages ​​would generate an exception), causes in JS that the value obtained is undefined:

> a = [0,1,2]
> a[8]
undefined

What is he for NaN?

• Check and make sure you are dealing with numbers.isNaN
• Quickly identify where the error is. (If you have done parseInt, parseFloat... and it returns NaN, you already know that the value is a null or an empty String)

Many JavaScript methods (such as the Number constructor, parseFloat, and parseInt) return NaN if the value specified in the parameter cannot be parsed as a number.

Knowing this:

var nullVar = null;
var stringVacio = "";
console.log(isNaN(nullVar)); //Retorna false 
console.log(isNaN(stringVacio)); //Retorna false

Why do they return false?

They return false because the value of an empty string ""or a nullis converted to0

So we can operate with them:

var stringVacio = "";
console.log((stringVacio +2));

So... where is he NaN?

Well, as it says in the quote at the beginning of the question, if we parse these values ​​before operating with them, we will obtainNaN

var stringVacio = "";
console.log((parseInt(stringVacio) +2));

The correct way to check with isNaNwould be:

var nullVar = null;
var stringVacio = "";
console.log(isNaN(parseInt(nullVar))); //Retorna true al hacerle el parseInt
console.log(isNaN(parseInt(stringVacio))); //Retorna true al hacerle el parseInt