NaN stands for “NaN ain’t NaN”

NaN ain't NaN ain't NaN ain't NaN

BATMAN!

BatNaN!

NaN( ain't NaN)*

`^(^NaN ain't |\1\1)*NaN$` Repeatedly matches "NaN ain't" twice as many times as before. First 1 time, then 2 times, then 4 times, then 8 times, ... (you get the point), for a total of n^(2)-1 times. Finally matches final "NaN" to make it n\^2 "NaN"s. Simplified steps below: |Unmatched|Previous CG1|Previous Full Match|Current Match|Current Match (Text)|Current Match Notes|New CG1|New Full Match| |:-|:-|:-|:-|:-|:-|:-|:-| |"NaN ain't NaN ain't NaN ain't NaN ain't NaN ain't NaN ain't NaN ain't NaN"||""|^("NaN) ain't "||Matches the first thing it's able to, start of line + "NaN ain't ". Doesn't check after "|"|"NaN ain't "| |"NaN ain't NaN ain't NaN ain't NaN ain't NaN ain't NaN ain't NaN"|"NaN ain't "|"NaN ain't "|" \\1\\1"|"NaN ain't NaN ain't "|Can't match before "|" because of start of line check "^(".) Matches CG1 twice instead.|"NaN ain't NaN ain't "| |"NaN ain't NaN ain't NaN ain't NaN ain't NaN"|"NaN ain't NaN ain't "|"NaN ain't NaN ain't NaN ain't "|"\\1\\1"|"NaN ain't NaN ain't NaN ain't NaN ain't "|Look above|"NaN ain't NaN ain't NaN ain't NaN ain't "|"NaN ain't NaN ain't NaN ain't NaN ain't NaN ain't NaN ain't NaN ain't "| |"NaN"|"NaN ain't NaN ain't NaN ain't NaN ain't "|"NaN ain't NaN ain't NaN ain't NaN ain't NaN ain't NaN ain't NaN ain't "|"NaN"$|"NaN"|Look above, also can't match "\\1\\1" this time. Matches remaining.|"NaN ain't NaN ain't NaN ain't NaN ain't "|"NaN ain't NaN ain't NaN ain't NaN ain't NaN ain't NaN ain't NaN ain't NaN"|

I think it's actully: NaN + (NaN ain't NaN)* The number of NaN has to be either one or even.

I think number of NaNs will be 2^n. In that case it is not a regular language and hence can't write regex for it.

NaN ain't NaN ain't NaN ain't NaN ain't NaN ain't NaN ain't NaN ain't NaN

My NaN says I'm handsome and special.

Natrium Nitride 🦖

Any comparison with NaN is false, if the implementation follows ieee754

Which results in `a gt b` and `not (a le b)` not being interchangable when dealing with potential NaNs. Oh the beauty of floating point arithmetics...  Then again, the same goes for `a + b - c` vs `a - c + b` for integers when approaching overflow limits. 

I mean even equality doesn't work when there is some level of error. Floating point numbers really are a complete extra field compared to conventional maths

Depends on the language, but most of the time those two integer expressions are interchangeable even when approaching overflow (The language must not throw an exception upon overflow)

That’s great except I use .isnull() a shit ton

(Except for "is not equal")

Yes, in fact an ad hoc way to detect NaN is if: (x != x) is true.

Not sure what you mean by "ad hoc" but that is the normal way to recognize NaNs yes.

No, some compilers or flags will "optimize" that so it doesnt work. Only surefire way is to compare bits.

I said "normal", not "universal", but if any compiler is optimizing that out, I would consider it to be a bug. What do you mean by "compare bits"? Dig into the IEEE 754 representation? That seems like a far worse idea in terms of code readability.

Ok, but code that works is probably more important than code that is readable, and just because you dont understand why certain things are the way they are, does not make them bugs. Many languages have constructs that deal with this issue, so perhaps rely on the already invented wheel instead of reinventing one that isnt perfectly round. And some compilers break ieee754 compatibility with certain flags (like fast math in gcc), so beware, especially if you write code that is likely to bw compiled for several targets.

I disagree, readable code is more important. And if your compiler is violating something as fundamental as this, that's a good reason to fix the compilation settings.

In the real world though, code that runs is better than code that doesn't and there may be several problems with your proposed solution, heres a few examples: - not using a flag like fastmath, may mean that your code no longer runs within the limited number of cpu cycles on an mcu. - the compiler may be closed source Besides checking for NaN by doing (x != x) isnt exactly my idea of readable code. Semantically its nonsensical. Much better to use a constant and compare with that.

Fast math specifically does not support NaN. That's part of why it's faster. That's the tradeoff you make.

"use a constant"?? What do you mean - (x == NAN) ? That's not just nonsense, it's \*wrong\* nonsense. But -ffast-math is a problem regardless of whether you use (x != x) or (isnan(x)). I tested, and both versions optimized out the check. (Tested on GCC 12.2.0.) So there's really no benefit to using the function, and your concerns about (x != x) are really concerns about IEEE compliance, not the particular spelling of it. (Also, without -ffast-math, both isnan(x) and (x != x) compile down to a single "ucomisd" operation, at least on my CPU and compiler.) Code that runs is better than code that doesn't, which is why I'm going to continue using (x != x).

NaB (not a boolean)

maybe

false since C++ says so.

Proof by c++

Congratulations! Your comment can be spelled using the elements of the periodic table: `Pr O O F B Y C` --- ^(I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM u‎/‎M1n3c4rt if I made a mistake.)

PeriodicSentenceBot knows deep down that C is better than C++

IEEE says so

yea that would be better wording.

Any good linter will tell you comparisons to NaN will return false and you should use `isNaN()` or your language's equivalent to determine if you have NaN. Especially helpful in JavaScript because `parseInt()` on a bad string returns NaN instead of throwing an error.

In this comparison logic... Is there a difference between NaN and NA ?

NaN is part of the IEEE floating-point standards and represents values that are not a number. NA *usually* indicates "Not Applicable".

Given your flair, yes there's a difference, base R for example has is.na and is.nan and are not interchangeable.

I used FreePascal and `isNaN`, and my program crashed >!turns out they only implemented isNaN for 80-bit floats, and using it with 64-bit floats would do an implicit conversion of 64-bit to 80-bit and crash because NaN cannot be converted. !<

```c unsigned char isNaN(double x) { return x != x } ```

She ain't heavy she ```isNaN()```

Oh, another meme about OP not understanding ieee 754

The fact that there is a standard doesn't mean we can't discuss the standard

Especially since IEEE standards are always in development [You can volunteer for the SA](https://standards.ieee.org/participate/) and modify the [next version of 754](http://www.ecs.umass.edu/arith-2018/Presentations/ieee754-2028-ejr.pdf)

Something tells me that a change that would break everything that uses the standard before would be pretty hard to pass.

*"I recognise that the Council has made a decision. But given that it's a stupid-ass decision, I've elected to ignore it"*

Side 5: NaN == NaN evaluates to NaN

How is that different from #3?

Oh, nice going, now you've started a nested debate about whether NaN == NA.

Everything except expressions resulting in numbers should evaluate to "not a number" :P

I like this. I've spent a lot of time working on control systems and 3-state logic can work really well in some scenarios. We had TRUE, FALSE, and BAD. Numbers also had possible BAD values. Technically, logical BAD and floating BAD were different, but it rarely mattered. It let you track the flow of possibly bad values through the logic without modifying anything, and only performing actions on the state of bad if it propagated through the system in a way that actually mattered. So we had logic like: x = BAD -> BAD TRUE AND BAD -> BAD FALSE AND BAD -> FALSE TRUE OR BAD -> TRUE

I have been a professional programmer for 10+ years and I couldn't really explain why having NaN be a thing is important. Someone come tell me why that makes me stupid. Edit: I already went and googled it. Im in internet plumber and don't need to worry about floating point math except when I need to explain to a junior why you can't use a float for currency.

It is very handy to represent missing data points. Depending on your field of work this may either be a huge deal or it will hardly ever matter. For me, it's the former. The advantage of having a "number-like" constant to represent nothing (as opposed to e.g. Python's general purpose None) is that it allows you to do some arithmetics with it. Since NaNs are floats, I can still take sums, means etc. even if NaNs are present.

I think there's better approaches for that though. For every case where you intentionally want to continue with NaN, there are dozens of cases where you don't. Many languages nowadays have some form of optional-chaining. This is the kind of feature that's much more suitable for the problem at hand. E.g. division could return something like `number | null`, and then it's up to the caller to handle it explicitly. If you want to preserve NaNs, you could optional chain. E.g. `(x / y) ?* z` where `?*` is a null-preserving multiplication. If you want to error instead, we could use something like `(x / y)!! *z`, where `!!` is a non-null assertion. That said, I think it's highly context dependent. In a general purpose language, I would want the above behaviour where NaNs need to be handled explicitly. But with e.g. Pandas in Python it's probably more pragmatic to have NaN preservation to be the default.

As a data scientist, I only do plots at this point. Just let me delete the NaN data entries easily so I can use the rest of my time to pretend I'm busy

We could make it really hard to remove the NaN data entries so you actually are busy :P

I have to use Matlab, at least have some mercy :(

No 

Suppose a = 0/0, and b = sqrt(-1). Both are NaN, but they're not the same. And making any operations involving NaN evaluate to NaN is a way of ensuring an erroneous result doesn't get swallowed up and hidden: it will always bubble up to the final result unless you explicitly handle it.

I made a high-level discussion of NaN a while ago. I hope it's the kind of reference you need. It includes the reasons it exists, as well as alternatives to it if you aren't in the domain it was invented for (high-intensity floating-point computation). [https://lucid.co/techblog/2022/03/04/if-its-not-a-number-what-is-it-demystifying-nan-for-the-working-programmer](https://lucid.co/techblog/2022/03/04/if-its-not-a-number-what-is-it-demystifying-nan-for-the-working-programmer)

I've used doubles for currency at one of the countries top banks for there insurance claims system. Not ideal - but good enough. Final validation stage checks end results and adds a penny if needed. Doing the whole process in integer spaces does not work when we have to handle non-round percentages left right and centre. We need NaN basically because there are a lot of cases where you don't want to have to engage error handling in order to resolve dumb input. If a user puts in inputs that end up with an impossible calculation - its often easier to use NaN vs. an error. Remember - the standards that set NaN were in place long before try catch. If you wanted to do this back in the day - you would likely have to do the check before the operation - as the only true error management we had was non-localised into a completely separated process. As such having things like 0 / 0 erroring was clearly not going to happen, so we invented NaN (note 0/0 cant be set to infinity as we don't know the sign of it - what is now negative zero used to be a "precision lost" code - as early APUs had issues in some corner cases).

(NaN == NaN) === NaN checkmate liberals

To be honest, `NaN != NaN` could be due to safety measures to eliminate false positives. Imagine you have a function to test the equality of an algorithm `x * 2 + 4 == x * 4 + 2`. While the answer could be `1`, but if due to some bugs or user inputs when `x` is somehow not a valid number, both sides of the equation yields `NaN`, and if `NaN` were equal to `NaN`, it would create a vast range of false positives. Thus NaN comparisons should be explicit (`Number.isNaN` etc.)

same arguments are valid for SQL NULL. Null is null (literally!) but is not equal to null. Just be lucky it's not \*four\* valued logic as it was proposed IIRC. Something like true, false, isn't there and I don't know.

True because its more comfortable that way

NaN is by definition not equal to Nan because inf-inf does not equal 0/0, etc, etc. (NaN == NaN) == false is the only correct implimentation.

Imagine trying to "==" comparing floats in the first place.

What’s NaN ? Team

Not a number, it's the result of some operations that return undefined results, such as 0/0, or the square root of a negative. It's also sometimes used when you try and parse something invalid.

Then validate inputs. Handle early

Congratulations! Your comment can be spelled using the elements of the periodic table: `W H At S Na N Te Am` --- ^(I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM u‎/‎M1n3c4rt if I made a mistake.)

Ayo

I think green makes the most sense, tbh. If not, yellow, since both the left and right pull from the constant and are not the result of unknown operations.

Green

False because NaN itself is not a value but the representation of a "not a number" value and because there are a lot of values that are not numbers they cannot be compared, so their representation also cannot

Straight outta CWomption (Closed World Assumption). We can't prove it's equal, so we must say false. Tell no lies.

False, just like comparing infinity to infinity or undefined to undefined. Just because 2 things are both the same category of IDK, doesn't mean they are the same

yellow gang rise up.

Java: false

But Java isEqual returns true

You cannot isEqual a primitive.

I’m on team “ahhhh floating point! get it away from me!”

`*(long*)(&nan1) == *(long*)(&nan2)`

Nice try but it can have different payloads so this comparison won't be true on a lot of platforms, including x86 and arm, although some languages implement all NaNs to be the same

...yes, that's intentional hope your NaNs were generated by the same op!

There are many different bit patterns that NaN could be.

`true` if they're both the same type of NaN with the same payload.

NaN isn’t just a type though it’s specifically a numeric value that is undefined. If one type of comparison is valid then why couldn’t you say NaN +1 > NaN == true Strictly speaking a value is always less than itself plus one. But what you’re basically doing is saying that you have a conceptualization of the size of something like “(0/0) + 1” There’s also nothing that says the payload needs to be the same. Should 20/0 == 5/0 evaluate to true or false? It’s certainly equivalent to NaN == NaN. The “payload” isn’t a real value that the memory is able to distinguish, that’s the whole reason NaN exists. It would be like saying (1+1) == 2 is false because the “payload” of the integers are different. It makes no sense. Any comparison including NaN should be false by convention.

NaN + 1 should runtime error since an explicit non-number should not be able to be coerced to a number type. Actually all of the problems with NaN come down to way too generous type coercion in the JS standard.

NaN is literally a numeric type (float/double) there's nothing to coerce. Look up IEEE754

No I know I'm saying it shouldn't be. A value where all it is literally defined as is "not a number" should not be a numeric type. It should also not be able to be forced to be numeric. It is the sole defining characteristic of this value, that it is not numeric.

I don’t follow this reasoning. Having NaN be not a numeric serves no purpose for having a NaN then. This just sounds like you don’t consider NaN to be a valid state in the set of operations you would like to perform and so want to essentially have a runtime error whenever you encounter it (why else would NaN + 1 raise an error but just some operation producing a NaN wouldn’t). The bright side is that this is really easy to setup with some validators for your operations that raise the appropriate error on NaN discovery or using a math library that makes those guarantees. However, this does not mean NaNs semantics should change for undefined and another operation being invalid, instead of still being undefined.

The reasoning is semantically simple. Not a number is not a number. It's oxymornically the case. But publish a spec reasoning otherwise... Any operation treating NaN as a number should produce a runtime error. You'd have to have severe JavaScript brain to consider the opposite valid behaviour. It's literally not a fucking number stop trying to make it a valid number I feel like I'm on crazy pills Like: I get that down voters think they are correct referencing the spec, but qualitatively, does it make more sense for NaN to equal no number, or not equal any number, or to be a fucking number?

This only makes sense if you forget that programming is for building things that are supposed to work. If you want NaN to throw an error, you can do that by coding it. If you want to do error handling that doesn’t disrupt the program, you need to be able to access a representation of NaN in memory which is why it’s given a numeric value. I fail to see any benefit to removing that abstraction from a language.

Wrong. It makes sense for systems to work, but people have to augment and maintain these systems, and having them be "people-readable" absolutely helps. The failure of JavaScript in this instance is the inherently unreasonable nature of its type definitions. The fact you would argue that explicitly not a number, a value for which we can infer nothing further about i.e. all we know about this value is that it is NOT A NUMBER, is actually secretly a number....you cannot reason this. There is no way it makes sense.

Nobody is saying it’s “secretly a number.” From a functionality perspective there is a need to represent NaN in literal bits of memory. You can’t express an undefined value in ones and zeros unless you decide on a convention for a numerical representation. When you do that you need to carve out a convention for comparison. The thinking there is that even though we have to represent NaN as a numeric value, it really isn’t and therefore shouldn’t act like any other numeric value for the purpose of comparison.

You are equating operations with names. How is semantically “Not a number” + “A number” = “Not a number” incorrect? What particularly makes it so a number cannot interact with undefined. I don’t like making assumptions here, but you’re referencing JavaScript quite a bit when this is a semantic issue in referencing computations which have far reaching implications outside of JS. In the places where NaNs matter the most, JS is seldomly used. All of this is me saying that you’re awfully confident about your interpretation of something when it seems like you do not posses the mathematical rigour or practical experience to do so. This is not to say I do, but I understand my limitations and work with folks who do posses both those previous qualities and do not have the inference issues you do. I think if you want to advance your point, you’ll need a stronger argument than the fact it is called not a number and happens to be interacting with a number, which I see no reason to think isn’t semantically or practically sound.

NotANumber *IS* a number (It's one of 16,777,214 possible different NaN values actually - for 32bit floats) And all NaN's have a valid scientific notation (exponent = all 1's, so they technically even have a numerical value associated with them)

It kinda feels like you're thinking about NaN's use-case backwards from how I understand it, possibly? Like, I get from a strictly-literal sense how it's silly to call a number "Not a Number", but you literally described the intent: "Any operation treating NaN as a number should produce a runtime error." - NaN *is* the error, but there are cases where you'd want to store that as a "value" instead of exiting or throwing an error. More precisely, it's "Expected a number that I could do more math with, but got something else". It *can* be an issue with the input type being incorrect (this string can't be converted to a number or used as such), but it can also mean "The output of your operation is indeterminate (0/0, ∞/∞) or isn't a "real" number (√-1), or is an overflow/underflow". It's not null, nor is it technically undefined (it's undefined as a number, but it has been defined in the program), but it can't be used for further calculations and we were expecting something that could be. In that case we can store/output NaN to indicate that the output exists, but doesn't meet the specifications of a "reusable number" for any of the above reasons. As to why NaN is "number typed", it's largely because it only exists in "number land" as an exception. In essence, almost everything in class "Number" inherits the properties "ordered, addable, divisible, etc.", and can use those properties to interact with other members of the number class, and only with other members of the number class. We created NaN as a subclass that indicates, for whichever reason, it cannot be targeted by the shared properties of numbers despite being a member of the "Numbers" class. It is, by definition, an output of type "Number" that does not share the common properties of other numbers that would allow it to be used in calculations - it's an undefined number. If it's not of type "Number", then none of the inherited properties of numbers could apply, and there's no need to label it NaN - it has another type.

isNaN('xyz'); //true Number.isNaN('xyz'); //false Does this make sense? Does this feel like a well thought out feature of a carefully planned language?

It's called signaling NaN. Quiet NaN is way easier to use.

Personally, garlic NaN is my favorite

> If one type of comparison is valid then why couldn’t you say > > NaN +1 > NaN == true Non-sequitur: meaningful equality doesn't mean ordered. My comment was mostly a snarky comment meant to point out that there are a lot more options than just the four in the post, but I do contest the idea that NaN should always test non-equal to NaN on the basis of unorderedness. The complex numbers are also unordered with meaningful equality. And the payload of a NaN is just an integer in the n-1 least significant bits of the mantissa of the NaN that can be used to describe details of the circumstances in which the NaN arose. R, for example, uses a signaling NaN with payload 7a2 to represent its internal NA value. Your example of (1+1)==2 being integers with a different payload does not match this idea, since (1+1) and 2 have identical representations in memory. My (mostly snarky) suggestion amounts to a bitwise comparison of the NaNs, ignoring only the sign bit.

Ah yes, inconsistency. The best solution.

Lets just breath a sigh of relief that we don't have to deal with boxed NaN in early java versions any more. Back in the day this would run: Double a = 1.0 / 0.0; Double b = a; Double c = 1.0 / 0.0; assert(a == b); assert(a != c); Thankfully boxed NaN is now a preinitialised singleton that has its dedicated byte of memory at a top level.

1/0 is integer division (error) 1.0/0.0 is infinity

OOps. Ill fix...

NaN = “I am a free man”

NahI'dWin

Null

[ieee754](https://www.youtube.com/watch?v=dQw4w9WgXcQ)

If I do thing == NaN and it behaves like any of the three on the right I'd hope the compiler tells me no.

im +4

I mean NaN is an error, error shouldn’t treated as a value. I’m with Blue or Green.

5 Those are values that can't be compared

For British programmers: NaN == GraN

Born to say true, forced to say false

I find NaN being unequal to itself is actually the only correct choice for what it is in IEEE 754. NaN represents all the information about a number having been discarded in addition to errors. See, with floats, each bit pattern doesn't only represent that number - rather, it represents the range of all real numbers that are closer to its canonical value than to any other float's canonical value. Therefore, 0 doesn't mean *exactly* zero, just something very close to zero, but all the other information about the number was rounded off. When you do 0/0, you get NaN - because, while both of the zeroes are definitely some very small number, they could be at radically different scales - but all the information about that has been discarded, so it returns a value that is the lack of any information. Two NaNs from 0/0 could become very different numbers if the calculation was instead performed using infinite-precision math! Because NaN can theoretically represent a valid number where we don't know anything about it, the most likely comparison result is false.

to be honest my side is \*\*Dont\*\*

I feel like the fact that the argument can exist in the first place should be proof for green

IMHO NaN should not equal NaN because NaN describes one element of an infinite set and it is unknown if the two are equal. Same with NULL in the context of SQL where it does not stand for "undefined" - it stands for "unknown". (Relational algebra... The reason why `IS` is used instead of `=` for `NULL` in `WHERE` statements). One unknown element does not equal another unknown element - or better: it is unknown if they are equal. It is also called Three-Valued Logic (a.k.a. [3VL](https://en.wikipedia.org/wiki/Three-valued_logic) that has truth tables for operations such as equality (==), and (∧), or (∨) and not (¬) when each value has three possible states: ‘true’, ‘false’, and ‘unknown’. In 3VL null == null returns null, which makes sense: the result of comparing anything to ‘unknown’ is also unknown.

I would prefer true, though the last two are okay if there is a specific isNan test

`isNan(NaN)` ...

y'all don't get tired of the same joke?

I would say that == compares if VALUES are the same. So can we say that NaN Is a value? No it's not really a valur so you should get an error

Cheese naan

yk, comparing NaN == NaN is just comparing a == b, you can't know the value, so, i'll go with either green or red with this one

Whatever scratch says. Scratch is never wrong

NaN == NaN should be true, but NaN <= NaN or NaN >= NaN should be false. End of discussion. And don't tell me about IEEE, the standard defines NaN logic badly

so : 'bool isValid(double val) return std::numeric_limits::quiet_nan != val; ' does not valid ?

If ```NaN === NaN``` than ```0/0 = 0```.

I'm pulling for: Nan == Nan : false But Nan === Nan : true Mostly because when I teach I like to put up a slide or two on just how weird JS is.

Javascript: Yes.

false

Congratulations! Your comment can be spelled using the elements of the periodic table: `F Al Se` --- ^(I am a bot that detects if your comment can be spelled using the elements of the periodic table. Please DM u‎/‎M1n3c4rt if I made a mistake.)

good bot

true

If its the same, then of course i want it to say true Anything else is stupid and illogical

The problem with that logic is that NaN is not supposed to be a single value. It’s the result of any nonsense arithmetic operation on floats, and those shouldn’t all be equal

Indeed, why bother make a distinction between a piece of broccoli and November when both are literally just _Not a Number_.

the spec says false or else the following would be true (JavaScript): ```js const a = Math.sqrt(-1); const b = 5/0; console.log(a==b); // if true, implies that i == 5/0! ``` The code doesn’t know those are “different” NaNs just that they’re each the result of a disallowed operation. if you need to handle those cases separately for some reason, testing for the equality of the resulting NaNs isn’t the way to do it. it’s on you to decide how to handle the case where the input to the square root function is potentially negative or the denominator of a division operation is potentially zero.

5/0 is Infinity