[KalMann]

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

[naet]

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.

[grogers]

Doesn't "1 + x == 2 + x" evaluate to true for any x with large enough magnitude? In general we should expect identities that hold true in "real" math to not hold in FP

[ema]

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

[monkpit]

NaN is, by definition, not equal to NaN because they’re not comparable, it does have a definitive Boolean representation - false is correct

[zahlman]

The concept of NaN long predates the language that uses ===, and is part of a language-agnostic standard that doesn't consider other data types. Any language choosing to treat the equality (regardless of the operator symbol) of NaN differently would be deviating from the spec.

[disgruntledphd2]

In R, NA (which is almost, but not quite like NaN) actually has separate types for each result, so you can have NA_boolean, NA_integer etc. Its super confusing.

[freehorse]

What would an `if (NaB) ... else ...` block do?

Either you throw an exception (and imo it is better to just throw an exception before that already, then) or else what you do determines what NaN === NaN actually evaluates to.

[sophrosyne42]

It should throw a compile-time error. Anything like this which allows an invalid or unmeaningful operation to evaluate at compile-time is rife for carrying uncaught errors at run-time.

[charcircuit]

Or a 3rd option is it should not be allowed similar to dividing by 0.

[steveBK123]

Typed nulls are good

[nikeee]

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.

[munificent]

I don't think that logic quite holds up because when you have two NaNs that do have the same bit representation, a conforming implementation still has to report them as not equal. So an implementation of `==` that handles NaN still ends up poking around in the bits and doing some extra logic. It's not just "are the bit patterns the same?"

(I believe this is also true for non-NaN floating point values. I'm not sure but off the top of my head, I think `==` needs to ignore the difference between positive and negative zero.)

[freehorse]

> NaN === NaN and some NaN !== NaN

In julia NaN === NaN evaluates to true but NaN === -NaN evaluates to false. Of course, NaN == NaN evaluates to false. I think it makes sense that in principle === looks at bit representations, but cannot think of any reason === is useful here, unless you want to encode meaningful stuff inside your NaNs for some reason. It reminded me of this satirical repo [0] discussed also here [1].

[0] https://github.com/si14/stuffed-naan-js [1] https://news.ycombinator.com/item?id=43803724

[bogdanoff_2]

Something like:

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

[JohnMakin]

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

[mbrubeck]

> two equal numbers divided by themselves equal 1

That's not true. For example: 0 == 0, but 0/0 != 1.

(See also +Infinity, -Infinity, and -0.)

[KalMann]

It doesn't really matter if NaN is technically a number or not. I find the standard "NaN == NaN is true" to be potentially reasonable (though I do prefer the standard "NaN == Nan is false"). Regardless of what you choose NaN/NaN = 1 is entirely unacceptable.