My understanding is that the reasoning behind all this is:
- In 1985 there were a ton of different hardware floating-point implementations with incompatible instructions, making it a nightmare to write floating-point code once that worked on multiple machines
- To address the compatibility problem, IEEE came up with a hardware standard that could do error handling using only CPU registers (no software, since it's a hardware standard)
- With that design constraint, they (reasonably imo) chose to handle errors by making them "poisonous" - once you have a NaN, all operations on it fail, including equality, so the error state propagates rather than potentially accidentally "un-erroring" if you do another operation, leading you into undefined behavior territory
- The standard solved the problem when hardware manufacturers adopted it
- The upstream consequence on software is that if your programming language does anything other than these exact floating-point semantics, the cost is losing hardware acceleration, which makes your floating-point operations way slower
It should return false, right? They are different types of thing, so they can’t be the same thing.
Or, maybe we could say that our variables just represent some ideal things, and if the ideal things they represent are equal, it is reasonable to call the variables equal. 1.0d0, 1.0, 1, and maybe “1” could be equal.
This is a matter of choice, not something with an objectively correct answer. Every possible answer has trade offs. I think consistency with the underlying standard defining NaN probably has better tradeoffs in general, and more specific answers can always be built on top of that.
That said, I don’t think undefined in JS has the colloquial meaning you’re using here. The tradeoffs would be potentially much more confusing and error prone for that reason alone.
It might be more “correct” (logically; standard aside) to throw, as others suggest. But that would have considerable ergonomic tradeoffs that might make code implementing simple math incredibly hard to understand in practice.
A language with better error handling ergonomics overall might fare better though.
NaN is just an encoding for "undefined operation".
As specified by the standard since its beginning, there are 2 methods for handling undefined operations:
1. Generate a dedicated exception.
2. Return the special value NaN.
The default is to return NaN because this means less work for the programmer, who does not have to write an exception handler, and also because on older CPUs it was expensive to add enough hardware to ensure that exceptions could be handled without slowing down all programs, regardless whether they generated exceptions or not. On modern CPUs with speculative execution this is not really a problem, because they must be able to discard any executed instruction anyway, while running at full speed. Therefore enabling additional reasons for discarding the previously executed instructions, e.g. because of exceptional conditions, just reuses the speculative execution mechanism.
Whoever does not want to handle NaNs must enable the exception for undefined operations and handle that. In that case no NaNs will ever be generated. Enabling this exception may be needed in any case when one sees unexpected NaNs, for debugging the program.
This reminds me of an interesting approach a student had to detecting NaNs for an assignment. The task was to count no-data values (-999) in a file. Pandas (Python library) has its own NaN type, and when used in a boolean expression, will return NaN instead of true or false. So the student changed -999 to NaN on import with Pandas and had a loop, checking each value against itself with an if statement. If the value was NaN the if statement would throw an exception (what could poor if do with NaN?) which the student caught, and in the catch incremented the NaN count.
NaN comes from parsing results or Infinity occurring in operations. I personally ends up more to use Number.isFinite(), which will be false on both occurrences when I need a real (haha) numeric answer.
- NaN is a floating point number, and NaN != NaN by definition in the IEEE 754-2019 floating point number standard, regardless of the programming language, there's nothing JavaScript-specific here.
- In JS Number.isNaN(v) returns true for NaN and anything that's not a number. And in JS, s * n and n * s return NaN for any non empty string s and any number n ("" * n returns 0). (EDIT: WRONG, sée below)
> That’s also the reason NaN !== NaN. If NaN behaved like a number and had a value equal to itself, well, you could accidentally do math with it: NaN / NaN would result in 1, and that would mean that a calculation containing a NaN result could ultimately result in an incorrect number rather than an easily-spotted “hey, something went wrong in here” NaN flag.
While I'm not really against the concept of NaN not equaling itself, this reasoning makes no sense. Even if the standard was "NaN == NaN evaluates to true" there would be no reason why NaN/Nan should necessarily evaluate to 1.
NaNs aren't always equal to each other in their bit representation either, most of the bits are kept as a "payload" which is not defined in the spec it can be anything. I believe the payload is actually used in V8 to encode more information in NaNs (NaN-boxing).
Tangentially related: one of my favourite things about JavaScript is that it has so many different ways for the computer to “say no” (in the sense of “computer says no”): false, null, undefined, NaN, boolean coercion of 0/“”, throwing errors, ...
While it’s common to see groaning about double-equal vs triple-equal comparison and eye-rolling directed at absurdly large tables like in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid... but I think it’s genuinely great that we have the ability to distinguish between concepts like “explicitly not present” and “absent”.
> That’s also the reason NaN !== NaN. If NaN behaved like a number and had a value equal to itself, well, you could accidentally do math with it: NaN / NaN would result in 1,
So, by that logic, if 0 behaved like a number and had a value equal to itself, well, you could accidentally do math with it: 0 / 0 would result in 1...
But as it turns out, 0 behaves like a number, has a value equal to itself, you can do math with it, and 0/0 results in NaN.
I'm sometimes wondering if a floating point format really needs to have inf, -inf and nan, or if a single "non finite" value capturing all of those would be sufficient
A similar issue occurs in SQL, where NULL != NULL. [0] In both bases, our typical "equals" abstraction has become too leaky, and we're left trying to grapple with managing different kinds of "equality" at the same time.
Consider the difference between:
1. "Box A contains a cursed object that the human mind cannot comprehend without being driven to madness. Does Box B also contain one? ... Yes."
2. "Is the cursed object in Box A the same as the one in Box B? ... It... uh..." <screaming begins>
Note that this is not the same as stuff like "1"==1.0, because we're not mixing types here. Both operands are the same type, our problem is determining their "value", and how we encode uncertainty or a lack of knowledge.
The D language default initializes floating point values to NaN. AFAIK, D is the only language that does that.
The rationale is that if the programmer forgets to initialize a float, and it defaults to 0.0, he may never realize that the result of his calculation is in error. But with NaN initialization, the result will be NaN and he'll know to look at the inputs to see what was not initialized.
Another use for NaN's is, suppose you have an array of sensors. Given enough sensors, you're pretty much guaranteed that some of the sensors will have failed. So the array needs to continue to work, even if degraded.
A failed sensor can indicate this by submitting a NaN reading. Then, and subsequent operations on the array data will indicate which results depended on the failed sensor, as the result will be NaN. Just defaulting to zero on failure will hide the fact that it failed and the end results will not be obviously wrong.
Also, NaN is the only value in JS that isn't === to itself, so if for some reason you want to test for strict value identity with the value NaN of type number, that's one way to do it:
I get the idea behind NaN != NaN, but has there ever been any instance where this design decision has made practical code better instead of becoming a tripping hazard and requiring extensive special casing?
I'm also not a fan of the other property that NaN evaluates to false for all three of <, > and =, even though I don't have a good idea what to do otherwise.
I think as programmers, we usually assume that "not (a > b)" implies "a <= b" and vice-versa and often rely on that assumption implicitly. NaN breaks that assumption, which could lead to unexpected behavior.
Consider something like this (in JS) :
function make_examples(num_examples) {
if (num_examples <= 0) {
throw Error("num_examples must be 1 or more");
}
const examples = [];
for (let i = 0; i < num_examples; i++) {
examples.push(make_example(i));
}
// we assume that num_examples >= 1 here, so the loop ran at least once and the array cannot be empty.
postprocess_first_example(examples[0]); // <-- (!)
return examples;
}
If somehow num_examples were NaN, the (!) line would fail unexpectedly because the array would be empty.
33 comments
[ 3.3 ms ] story [ 50.1 ms ] threadEquality on things that it doesn't make sense to compare returning false seems wrong to me. That operation isn't defined to begin with.
By shipping with undefined, JavaScript could have been there only language whose type system makes sense... alas!
- In 1985 there were a ton of different hardware floating-point implementations with incompatible instructions, making it a nightmare to write floating-point code once that worked on multiple machines
- To address the compatibility problem, IEEE came up with a hardware standard that could do error handling using only CPU registers (no software, since it's a hardware standard) - With that design constraint, they (reasonably imo) chose to handle errors by making them "poisonous" - once you have a NaN, all operations on it fail, including equality, so the error state propagates rather than potentially accidentally "un-erroring" if you do another operation, leading you into undefined behavior territory
- The standard solved the problem when hardware manufacturers adopted it
- The upstream consequence on software is that if your programming language does anything other than these exact floating-point semantics, the cost is losing hardware acceleration, which makes your floating-point operations way slower
Or, maybe we could say that our variables just represent some ideal things, and if the ideal things they represent are equal, it is reasonable to call the variables equal. 1.0d0, 1.0, 1, and maybe “1” could be equal.
That said, I don’t think undefined in JS has the colloquial meaning you’re using here. The tradeoffs would be potentially much more confusing and error prone for that reason alone.
It might be more “correct” (logically; standard aside) to throw, as others suggest. But that would have considerable ergonomic tradeoffs that might make code implementing simple math incredibly hard to understand in practice.
A language with better error handling ergonomics overall might fare better though.
NaN is a value of the Number type; I think there are some problems with deciding that Number is not compatible with Number for equality.
We just need another value in the boolean type called NaB, and then NaN == NaN can return NaB.
To complement this, also if/then/else should get a new branch called otherwise that is taken when the if clause evaluates to NaB.
As specified by the standard since its beginning, there are 2 methods for handling undefined operations:
1. Generate a dedicated exception.
2. Return the special value NaN.
The default is to return NaN because this means less work for the programmer, who does not have to write an exception handler, and also because on older CPUs it was expensive to add enough hardware to ensure that exceptions could be handled without slowing down all programs, regardless whether they generated exceptions or not. On modern CPUs with speculative execution this is not really a problem, because they must be able to discard any executed instruction anyway, while running at full speed. Therefore enabling additional reasons for discarding the previously executed instructions, e.g. because of exceptional conditions, just reuses the speculative execution mechanism.
Whoever does not want to handle NaNs must enable the exception for undefined operations and handle that. In that case no NaNs will ever be generated. Enabling this exception may be needed in any case when one sees unexpected NaNs, for debugging the program.
after all, the usual WTF lists for JS usually have a stringified NaN somewhere as part of the fun.
NaN should have been NaVN, not a valid number.
- NaN is a floating point number, and NaN != NaN by definition in the IEEE 754-2019 floating point number standard, regardless of the programming language, there's nothing JavaScript-specific here.
- In JS Number.isNaN(v) returns true for NaN and anything that's not a number. And in JS, s * n and n * s return NaN for any non empty string s and any number n ("" * n returns 0). (EDIT: WRONG, sée below)
because a <= b is defined as !(a > b)
then:
5 < NaN // false
5 == NaN // false
5 <= NaN // true
Edit: my bad, this does not work with NaN, but you can try `0 <= null`
While I'm not really against the concept of NaN not equaling itself, this reasoning makes no sense. Even if the standard was "NaN == NaN evaluates to true" there would be no reason why NaN/Nan should necessarily evaluate to 1.
Does Numpy do the same? That’s where I usually meet NaN.
https://en.wikipedia.org/wiki/NaN
Also you even have different kinds of NaN (signalling vs quiet)
While it’s common to see groaning about double-equal vs triple-equal comparison and eye-rolling directed at absurdly large tables like in https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid... but I think it’s genuinely great that we have the ability to distinguish between concepts like “explicitly not present” and “absent”.
So, by that logic, if 0 behaved like a number and had a value equal to itself, well, you could accidentally do math with it: 0 / 0 would result in 1...
But as it turns out, 0 behaves like a number, has a value equal to itself, you can do math with it, and 0/0 results in NaN.
NaN is an error monad.
[0] https://www.ams.org/journals/tran/1945-058-00/S0002-9947-194...
Consider the difference between:
1. "Box A contains a cursed object that the human mind cannot comprehend without being driven to madness. Does Box B also contain one? ... Yes."
2. "Is the cursed object in Box A the same as the one in Box B? ... It... uh..." <screaming begins>
Note that this is not the same as stuff like "1"==1.0, because we're not mixing types here. Both operands are the same type, our problem is determining their "value", and how we encode uncertainty or a lack of knowledge.
[0] https://en.wikipedia.org/wiki/Null_(SQL)
The rationale is that if the programmer forgets to initialize a float, and it defaults to 0.0, he may never realize that the result of his calculation is in error. But with NaN initialization, the result will be NaN and he'll know to look at the inputs to see what was not initialized.
It causes some spirited discussion now and then.
A failed sensor can indicate this by submitting a NaN reading. Then, and subsequent operations on the array data will indicate which results depended on the failed sensor, as the result will be NaN. Just defaulting to zero on failure will hide the fact that it failed and the end results will not be obviously wrong.
if(x !== x) ... // x is NaN
I'm also not a fan of the other property that NaN evaluates to false for all three of <, > and =, even though I don't have a good idea what to do otherwise.
I think as programmers, we usually assume that "not (a > b)" implies "a <= b" and vice-versa and often rely on that assumption implicitly. NaN breaks that assumption, which could lead to unexpected behavior.
Consider something like this (in JS) :
If somehow num_examples were NaN, the (!) line would fail unexpectedly because the array would be empty.