NaN, the not-a-number number that isn't NaN

I definitely support NaN not being equal to NaN in boolean logic.

If you have x = "not a number", you don't want 1 + x == 2 + x to be true. There would be a lot of potential for false equivalencies if you said NaN == NaN is true.

--

It could be interesting if there was some kind of complex NaN number / NaN math. Like if x is NaN but 1x / 2x resulted in 0.5 maybe you could do some funny mixed type math. To be clear I don't think it would be good, but interesting to play with maybe.

Maybe the result of NaN === NaN should be neither true nor false but NaB (not a bool).

I think a better reasoning is that NaN does not have a single binary representation but in software, one may not be able to distinguish them.

An f32-NaN has 22 bits that can have any value, originally intended to encode error information or other user data. Also, there are two kinds of NaNs: queit NaN (qNaN) and signalling NaNs (sNaN) which behave differently when used in calculations (sNaNs may throw exceptions).

Without looking at the bits, all you can see is NaN, so it makes sense to not equal them in general. Otherwise, some NaN === NaN and some NaN !== NaN, which would be even more confusing.

Something like:

// Optimize special case if (x == y) return 1; else return x/y;

Because NaN is defined as a number and two equal numbers divided by themselves equal 1

In the same spirit, the `char` type default initializes to 0xFF, which is an invalid Unicode value.

It's the same idea for pointers, which default initialize to null.

Try subtraction. But also, not all calculations are purely using mathematical operations. You might calculate two numbers from two different code paths and compare them.

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

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 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 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.

> Shouldn't an operator on incompatible types return undefined? ;)

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.

JavaScript has also TypeError which would be more appropriate here. unfortunately undefined has never been used well and it's caused much more pain than it has brought interesting use cases

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.

"return undefined" is incoherent in almost every language, and IEEE754 predates JavaScript by a decade.

>Shouldn't an operator on incompatible types return undefined? ;)

Please no, js devs rely too much on boolean collapse for that. Undefined would pass as falsy in many places, causing hard to debug issues.

Besides, conceptually speaking if two things are too different to be compared, doesn’t that tell you that they’re very unequal?

You’ve opened a rabbit hole for me

In the error monad NaN = NaN (or Nothing = Nothing or None = None, depending on your terminology) because mathematical equality is an equivalence relation. There are many foundational debates about equality, but whether or not it is an equivalence is never the question.

The root of the problem, completely overlooked by OP is that IEEE 754 comparison is not an equivalence relation. It's a partial equivalence relation (PER). It does have its utility, but these things can be weird and they are definitely not interchangeable with actual equivalence relations. Actual, sane, comparison of floating points got standardized eventually, but probably too late https://en.wikipedia.org/wiki/IEEE_754#Total-ordering_predic.... It's actually kinda nuts that the partial relation is the one that you get by default (no, your sorting function on float arrays does not sort it).

Not at all sufficient. NaN typically means that something has gone wrong—e.g. your precision requirements exceed that of the floating point representation you've selected, you've done a nonsensical operation. inf and -inf might be perfectly acceptable results depending on your application and needs.

Opened Web Inspector in Safari and pasted the above. (I knew what to expect but did not know how it would work … me trying to figure out what subtracting 1 from a string (ASCII?) would give you. But very related to this post.)

Indeed, this shtick was funnier 13 years ago. https://www.destroyallsoftware.com/talks/wat

JavaScript is a quirky, badly-designed language and I think that is common knowledge at this point.

SQL more elegantly introduces ternary logic in this case, where any comparison with NULL is itself NULL. This is sadly not possible in most languages where a comparison operator must always return a (non-nullable) boolean value.

For the built-in float type in Python, the behaviour is a bit funny:

    >>> nan=float('nan')
    >>> a=[nan]
    >>> nan in a
    True
    >>> any(nan==x for x in a)
    False

In a perfect world, in my opinion is that they are incompatibles, and the equality operation should return False in both cases.

But equality is a very complicated concept.

I guess if the values are incomparable != preserves PEM

But Boolean algebra is a lattice, with two+ binary operators were two of those are meet and join with a shared absorbing property.

X == not not X being PEM, we lose that in NP vs co-NP and in vector clocks etc…

But that is just my view.

Yes, in numpy we also have that `np.float64(nan) != np.float64(nan)` evaluates to true.

> And in JS, s * n and n * s return NaN for any non empty string s and any number n ("" * n returns 0).

No? It is easy to verify that `"3" * 4` evaluates to 12. The full answer is that * converts its operands into primitives (with a hint of being number), and any string that can be parsed as a number converts to that number. Otherwise it converts to NaN.

I always thought of NaN as more of the concept of not-a-number the way that infinity in math is not a specific value but the concept of some unbounded largest possible value.

Therefore, trying to do math with either (for example: NaN/NaN or inf./inf.) was to try to pin them down to something tangible and no longer conceptual — therefore disallowed.

It can usually be implemented like this. No need for strings.

fun isNan(n) = n != n

IEEE 754 specifically prohibits that definition, and JavaScript indeed evaluates `5 <= NaN` to false.

What's wrong with that? No engineering is 100% strict; there is always ambiguity at the edges

What's the difference between something that's "not a number" and something that's "a number but not a valid one"?