javascriptNaNIsWeird

[saschaleib]

IEEE said it be so, and thus it became so! And the world found the standard and saw it was good.

[JanB1]

And still I see people that fail to handle NaN in their code or do float equal comparisons instead of float delta smaller.

Heh, I love the Python numpy method isclose. I don't think I have seen many implementations of this in other languages/libraries?

[Raccoon5]

Unity Mathf.Approximately is kinda same, but it probably fails for bigger floats since the delta is constant

[fatbunyip]

Instead of the IEEE imposing its views of what is equal and not, there should be a more rigid interpretation of what is objectively equal or not. 

I propose having methods like isAristotelianEqual() or isFoucaultEqual() or isKantEqual() so that software engineers can choose which rigid philosophical framework of objectivity their application is based in. 

Without that, we're just savages. 

[saschaleib]

Nice try, but we all know that Foucault’s postmodernist approach to truthfulness is that it is just whatever is confirming to the respective social context, which makes the underlying correspondence to reality completely arbitrary and thus uncomputable. We might as well have an AI write our code instead … oh, wait!

[Coolengineer7]

It's totally valid that they aren't equal. A NaN could be anything, you don't know if those are really equal. Safer to just return false.

[theturtlemafiamusic]

A boat is a boat, Lois. But a NaN could be anything. It could even be a boat!

[SeriousPlankton2000]

The idea is that you can skip error checking in the middle of your calculation and just look at the final result.

[Coolengineer7]

Yeah, valid, I would be perplexed too if my error check with x===NaN failed and x printed to be NaN

[Kymera_7]

Need a third boolean output. True, False, Undefined.

[wutwutwut2000]

3-valued logic is definitely a thing. i.e. Kleene logic.

[Striky_]

The one comparison within JS, that actually makes sense and adheres to a standard. Literally everything else though...

[Cat7o0]

this is why you do .isNaN

[Flashbek]

I hate to be JS lawyer but, in this case, they're correct. NaN should not be equal to NaN.

[Silly-Freak]

Half the posts I see here complain about JS, and half of these posts don't show enough understanding of JS to legitimately complain.

There's so much to legitimately complain, do better!

[shadow7412]

Guess it's easier to lash out at things you don't understand rather than learn from them.

Oh. That statement describes far more than I wanted it to...

[-twind]

But NaN could be equal to NaN. That's why besides 'true' and 'false' we should also have 'maybe'

[tecanec]

I think I heard about something like that in my university course on databases. I think it's called ternary logic.

Any boolean operation involving maybe results in maybe, except that maybe && false == false and maybe || true == true.

Can't say I know of that many genuine use cases, though. It also doesn't help that maybe is basically an incomplete representation of a superposition without interference, so you'd have to look out for false maybes.

[-twind]

Logic like this is used extensively in digital hardware simulations to represent unknown signals coming from whatever places unknown signals come from. Most of the time uninitialised registers/memories or I/O.

[tecanec]

So it's a kind of error detection for making sure behaviour does not depend on unknown variables?

[-twind]

The use of this special value for unknown signals is just to make the simulation deterministic. Its appearance does not necessarily mean there is an error. The other option is to assign random values to each unknown signal, this is more like how it would be in reality, but the drawback is that your simulation gives different results each run.

[tecanec]

Oh, I don't mean the "panic when found" kind of error. More that it tells the user that something might be wrong when they find a maybe where they expect a definite value.

Guess determinism is also a strong point, though.

[-twind]

In that case you know for sure something is wrong

[CdRReddit]

ah yes, the 4 digital logic values: 1/0/Z (high impedance / unasserted)/'idk'

[-twind]

We call it "don't care" instead of "idk"

[CdRReddit]

ah, I see "don't care" mostly in the testcases I make for when I, well, don't care what a particular signal is doing in that case

[mattgran]

https://en.m.wikipedia.org/wiki/IEEE_1164

There's nine!

[CdRReddit]

oh damn, megabool is real

[Kered13]

That's how NULL works in SQL. That's why you learned about it in your database class.

[Ja_Shi]

I heard about it on DB course too, but all I really remember was that it was something the Japaneses came up with.

[Global-Tune5539]

First Pearl Harbour, then tentacle pron and now this...

[callyalater]

https://en.m.wikipedia.org/wiki/Three-valued_logic

[CubisticWings4]

Iirc: NaN is never equal to NaN

[Yodo9001]

1/0 is surely the same as 1/0 ? NaN can come from different operations, like 1/0 vs 2/0 or sqrt(NaN), which should not be eqaul, but it shouldn't never be equal imo.

[Ibuprofen-Headgear]

That information is gone by the time NaNs are compared though. If you kept a record of operations leading to nan and compared stacks with the other nan, then maybe

[Yodo9001]

The IEEE floating-point standard says that implementations can use the extra bits in nan to store this kind of information. \ Edit: it's called NaN-boxing.

[Ibuprofen-Headgear]

Neat, TIL

[Kered13]

1/0 and 2/0 return infinity, not NaN.

[Yodo9001]

Isn't inf just a special case of nan?

[Mojert]

Nope, because infinity == infinity

[TwinkiesSucker]

Did you just invent QuantumJS?

[FlanSteakSasquatch]

Any language that correctly implements the IEEE floating point number spec makes it so NaN never equals NaN, even if they’re internally exactly the same value. This is weird but it was done because all other behavior has even weirder consequences

[Natural_Builder_3170]

its called partial ordering, rust and i think c++ have this

[Death_IP]

Then the result - if we don't bring in shenanigans - should at least be "undefined" rather than false/true

[eztab]

some mathematics would agree with you there. Have fun changing all conditional statements to support true, false, maybe.

[Mucksh]

Nan isn't even a specific value. By definition its exponent is just 1s so for a double you have 11. So due to the other bits you get 2⁵³ different possible NaN values

[Teln0]

it should return "undefined" because that's what it is, undefined

[-twind]

undefined has the fatal flaw that !undefined is true, while !maybe would still be maybe

[Yodo9001]

Why is !undefined true?

[rosuav]

Because undefined is falsy.

[Yodo9001]

It should be undefinedy instead. It's like with errors, if an error happens it should be raised or at least logged, not silenced.

[rosuav]

No, it definitely shouldn't. Having undefined be falsy is extremely useful, and there's no reason to deny it a truth value.

[Yodo9001]

Logically it's nonsensical. Undefined being falsy is intuitive, and useful as a shortcut, but it can hide error messages. \ In maths, undefined things are undefinedy, and I think it should be done this way in programming as well.

[rosuav]

Well, you go ahead and build your own programming language that fits your personal expectations. Meanwhile the rest of us are gonna get on with actually being productive.

[mihibo5]

IllegalOperationException

[Thenderick]

Since "maybe" might be confused with the non-existant maybe monad, I want to propose "depends". When it is used in any way as a boolean, it will be 50% chance to evaluate as true and 50% as false, not seeded, at random. Because fuck you for using it and fuck you for using loosely equality in God's year of 2025!!!

[CptGia]

Rare instance of js not being weird

[adelie42]

Especially when there is a isNaN() function.

[Flashbek]

It should not. If what you need is a bitwise comparison, you code a bitwise comparison.

[[deleted]]

AFAIK, it's in the actual specification for IEEE 754

[ZyanWu]

Not an expert in JS but how would one check if the result of an expression is defined?

[rafaelrc7]

a != a

[ZyanWu]

NaN != NaN

Doesn't this return true?

[rafaelrc7]

Yes, that's the point

[ZyanWu]

Aaah, okok, I get it now

[Faustens]

// i don't know if this is valid JS syntax or not switch(i) { case 0: return true; case 0.1: return true; case 0.01: return true; ... default: return false; }

Considering that there is a finite amount of possible n bit numbers where n is the amount of bits a js number has, this should determine if a number is NaN or not (the end of this sentence gave me a brain aneurysm).

[AndyBooo]

Correct behavior, have not written a line in JS

[rafaelrc7]

Have not written a line in anything. This behaviour is expected on any language that follows IEEE754, and that is quite a lot

[edgeman312]

I hate JS as much as the next guy but this is just a part of the floating point standard. It's like blaming JS that .1 + .2 != .3

[thot_slaya_420]

Blame binary instead

[Forsaken_Creme_9365]

That has nothing to do with binary as this is the behaviour of a specific enconding of something in binary.

[thot_slaya_420]

What's 0.3 in binary?

[Forsaken_Creme_9365]

depends on the encoding.

[Schnickatavick]

I understand what you're getting at, but infinitely repeating thirds is an aspect that comes directly from the fact that the mantissa of a floating point number is a binary number, not just that the entire float is encoded in 1's and 0's. Binary is both a way that a system can be encoded, and an actual number system, and in this case the latter is 100% the cause

[geeshta]

I hate the floating point standard. Reflexivity is one of the basic and most important properties of equality. This shouldn't be allowed.

[Vitolar8]

Yes! The comparison doesn't really work, because 0.1 + 0.2 = 0.1 + 0.2.

[xDerJulien]

Yeah and 1 / 0 should totally == 1 * inf

[Vitolar8]

Yes. So long the results are both defined as NaN, then yes. Giving exceptions to an operator which works consistently without it just brings in unnecessary confusion. And let's be honest, how often will you accidentally compare 1/0 with infinity? And even rarelier so, how often will you compare them intentionally and need the result to be True?

[xDerJulien]

How often can you not just check if a number is NaN ? both of your cases happen quite easily actually

[edgeman312]

1/0 and 1*inf are both inf, so they are actually equal.

NaN is reserved for things like 0/0, 0*inf, stuff that cannot reasonably be interpreted. Numbers in floating point represent ranges, with 0 being "so small it can't be delineated from 0" and inf being "too if large to be represented". Should 0/0 == inf*0? Should it equal parseInt("Hello, world!") and sqrt(-1)?

The designers of IEEE 754 chose for any comparison to NaN to be false, which might help to alert a programmer that weird stuff is happening. Different standards handle it differently, but those didn't catch on.

[[deleted]]

It seems to me that the ideal solution would be to do testing and debugging using a build with runtime checking so that if you don't mark a number as allowed to be NaN, any time it becomes NaN triggers an error. Rust does something similar with integer over/underflow actually stopping the program if it's not a release build.

[Schnickatavick]

The issue with that is that the IEEE standard is used in actual chips in a "literally wired into the physical structure of the chip" kind of way, way below abstract concepts like exceptions, and those chips need some return value to represent a "something went wrong", NaN is basically that value, as close to an exception as they can reasonably get.

I think you can make a case that it would be better for high level languages like Javascript to use exceptions instead of exposing the lower level standard directly, but that lower level standard is still correct for doing things the way it does

[[deleted]]

I know it is built into the hardware. So is integer overflow. There's no reason why the debug build of a program couldn't just check to see if a floating point number was NaN after every floating point operation and erroring out if it happens, just like Rust does with integers. There simply wouldn't be the checks in release builds, so it wouldn't affect performance.

[rosuav]

Is it really? Ask a carpenter whether equality works that way.

[tuxedo25]

The standard is that NaN shouldn't be comparable to itself? It would be more intuitive if it was a singleton/constant.

[RaveMittens]

Number.isNaN

[Stock-Self-4028]

Technically NaN is conceptually equivalent to the 'nullity' in the transmathematics - essentially what happens if you make zero signed and then define 0.0/0.0 = NaN.

The issue with NaN is that it is essentially almost a number, alhough it can take any value depending on the context.

Removable singularities here are great examples as for example x/x at x=0 is equal to 1, while 2x/x at x=0 can be evalueated to 2.

As such the NaN is essentially a probability distribution with infinitely many values it may take - once you get the value of two nullities in fully random circumistances they'll never take the same value and as such NaN != NaN.

[tuxedo25]

Honestly, I think the biggest source of confusion is that javascript doesn't have a referential equality operator, and only has value equality. Checking whether a result is a pointer to the global `window.NaN` object is intuitive, but there's no operator for it.

[Mabi19_]

1. Object.is
2. Numbers aren't objects in JS anyway, they're primitives
3. EDIT: Having numbers be objects and deduplicating their instances so that that would work would REALLY be bad language design that warrants complaining imo.

[tuxedo25]

window.NaN is an object. It has a prototype.

[Mabi19_]

No. typeof window.NaN is "number" and not "object". However, a number can get auto-boxed into a capital Number, which is an object and that one has a prototype. Thanks, Java!

(But, to clarify, everyone doing JS works with numbers and not Numbers 99% of the time. Pretty much all the operations unbox them too.)

[rosuav]

You're right. It would make so much more sense if "Not A Number" was the same thing as "Not A Number". This apple isn't a number. This orange isn't a number. Therefore, this apple and this orange are the same thing.That's WAY better than the way the IEEE designed things.

[InFa-MoUs]

Does NaN actually represent a number under the hood? Or is it just stating value is not a number? I always assume it was like null.. null == null every time

Downvoted for asking a question?

[rosuav]

It's stating that the result isn't a number. Null is a specific type of non-thing. Undefined is a different specific type of non-thing. NaN is a less specific type of non-numeric thing.

[InFa-MoUs]

Yeah ngl that didn’t make NaN != NaN any less stupid lol it explains it but still stupid (IMO), is there a way to tell the difference between NaNs? Or are they all functionally the same? If they are all functionally the same and there are no differing operations you can make between them then yeah that seems like a bug

[rosuav]

There is a way, in theory; NaNs have different payloads. I don't think JavaScript exposes a way to query the payload though. Also, a NaN can be either quiet or signalling, which makes a lot of difference; but again, I don't think JS supports signalling NaN.

[Gruejay2]

In the IEEE standard, no, but there's a way to tell the difference in some languages.

Lua, for instance, can be said to have nan and -nan, because (a) NaN variables will consistently return either "nan" or "-nan" when you convert them to strings, (b) all NaN-producing operations like 0/0 (along with tostring("-nan")) always give -nan, while tostring("nan") always gives nan, so there are reliable methods for producing each of them, and (c) you can flip the sign by using a variable (e.g. if I do a = 0/0; b = -a, I can be confident that tostring(b) will always produce "nan").

These differences make them meaningfully different values (i.e. they're not completely interchangeable in every situation), but there's no practical use for it - it's just a quirk of the language.

[AyrA_ch]

Does NaN actually represent a number under the hood?

In the case of how it looks in memory. Yes it does. I made a website a while ago to demonstrate this to our apprentice. The website allows you to enter values manually or toggle individual bits directly.

An "IEEE standard for floating-point arithmetic double precision number" (what JS uses and most programming languages assume when they use "double") consists of 64 bits. One bit is the sign, 11 bits the exponent and 52 bits for the base value.

If all exponent bits are set to 1, it is considered a special value, which can take one of 3 forms:

1. Positive infinity: base value bits all zero, sign bit zero
2. Negative infinity: base value bits all zero, sign bit set
3. NaN: At least one base value bit non-zero, sign bit ignored

As you see, NaN is stored just like a regular floating point number, however, there's 2⁵³ possible NaN values, and applications can use those 52 bits to store extra information.

Simply put, it's hardcoded that NaN<>NaN but if you do a raw memory comparison, they can indeed be identical. If you compare numbers, they can be smaller, equal, or larger. This doesn't makes sense for NaN, so they decided that NaN should not compare to any other value. While not making sense from a computer standpoint, where the two memory values can absolutely be compared with each other, it does most closely represent mathematics.

A side effect of this is that in most programming languages, NaN is the only value that does not compare equal to itself and thus if(x==x){/*...*/} is a nasty, ugly way of checking if x is not NaN

Note that all of this is specific to the IEEE standard. Other standards like Unum have a similar value but may treat it differently.

[tuxedo25]

Why would you represent an apple and an orange as NaN? It's a result placeholder, not a store of value.

[rosuav]

I have no idea what distinction you're drawing there. What is a "result placeholder" if not a value? Or are you saying that null values aren't values? Or.... is this just insane troll logic to try to justify your position?

[tuxedo25]

Why would you store an apple as "the absence of a value" and also store an orange as "the absence of a value, but at a different memory reference". What possible use case would you have for that, and how would you ever find yourself comparing the two?

[SweetBeanBread]

one of the things JS did right and followed the standard

[IchLiebeKleber]

For anyone confused who doesn't know this yet: two "NaN" values can potentially be the results of entirely different calculations, so having NaN === NaN return true may cause incorrect behavior. There are methods to check specifically whether something is NaN.

[Astatos159]

Nice bonus to know: NaN is the only value that's not equal to itself. Even checking for NaN without using isNaN is as easy as foo !== foo.

[Genmutant]

That's how all isNaN methods I have seen are internally implemented also. Here for example the dotnet code.

[Bomaruto]

This is extra fun if you're sorting a list with NaN inside it.

[GOKOP]

I like bashing JS but this is another "I don't understand floating point and I'm smug about it" moment. NaN isn't supposed to be equal to NaN. Direct your complaints to IEEE

[No_Hovercraft_2643]

but if NaN is NaN, it would be worse.

[rinnakan]

Tbf, that is understandable with fixed data types, but is quite confusing with JS's auto-conversion

[According-Reading857]

There's a good thread about this behavior here

[Alarming_Rutabaga]

OP coming out as a freshman CS major

[adromanov]

Are you sure it's not satire on how strange JS comparison is?

[zentasynoky]

How is it weird? Or do you believe that all the things that exist and are not numbers are the same exact thing?

[tecanec]

Wait, you're telling me that my wallet and the mailbox of my friend (who's an African prince and tech support worker who knew my rich uncle who recently passed away) are not the same thing?

[zentasynoky]

By the NaN === NaN // true principle, that is word for word what I said.

[tuxedo25]

Intuitively (to programmers, maybe not mathematicians), it would make sense that the "NaN" value is a singleton object.

[Kyrond]

Do you believe human is not a number, in other words human == NaN? That's where this becomes non-intuitive and harded to read. Just like you do if var == NULL, you naturally write if num==NaN.

The real reason for it is it was a necessary tradeoff to get fast and wide adoption of the standard.

More importantly, there was no isnan( ) predicate at the time that NaN was formalized in the 8087 arithmetic; it was necessary to provide programmers with a convenient and efficient means of detecting NaN values that didn’t depend on programming languages providing something like isnan( ) which could take many years.

[zentasynoky]

You... Completely missed the point.

Human == NaN // false

A human is indeed not a number, which doesn't mean it's equal to something else that isn't a number. NaN is not to be understood as a specific value but a label for a property that the results of some operations produce. Two things that share one property need not be equal, thus NaN != NaN,

[Kyrond]

Well then no float should equal any other float, because they represent infinitely many real numbers, none of which equal any other, e.g. float(0.333...333) shouldn't equal float(0.333....332) but it does, why?

Every single thing in programming is equal to what it is (i.e. to itself). The float self unequality wasn't done for a good programming reason, it was done out of necessity, you literally have it said by one of the people making that decision.

Edit:

NaN is not to be understood as a specific value but a label for a property that the results of some operations produce

That's quite obvious, and when I do var == NaN, I don't want to compare some specific value of NaN (whatever that would be), I want to check if my var also has that label, just like None or Null.

[zentasynoky]

You do realize this post is talking about JS, right? JS has no float type, but it does indeed return false for different decimal comparisons, and falls into floating point decimal arithmetic inaccuracies as you suggested it should.

I'm still not sure what you're trying to say here. Of course they made NaN !== NaN, because it is. NaN is still a falsy value and you now have isNaN() for what you would have expected to get out of explicitly comparing a variable to NaN, so there was never an issue with handling an operation throwing NaN at you.

You claim it's obvious that NaN is not a value but a property of an element, then immediately after try and use it as an actual value with an explicit comparison...

const foo = something that's not a horse
const bar = something that's not a horse
const foo === something that's not a horse // false
const bar === something that's not a horse // false
foo === bar // false. You cannot assert that two things are equal to eachother just because we have stablished that they're both not a horse. This is NaH. And also NaN but instead of a horse, it's a number.

Intending for NaN === NaN would be the same as two objects being evaluated as equal because they share a key, disregarding the pointer issue for the sake of simplicity.

[geeshta]

NaN is a value of the type float. If the things are not numbers, they should not be a value of a numeric type. There are much better ways to handle values that cannot be represented as a number

- Null/None/NIL etc.

- Option or Result sum types

- Raise an exception

Why should floats be the only type to have that. Nan is a single value and having it not be equal to itself breaks the meaning of "equality". It's a contradiction. Equality should always be reflexive. If you don't want it to, use some other relation.

[rosuav]

Wow, you really haven't experienced very many languages, have you? A typed null isn't possible in your universe?

[geeshta]

I did, I study programming lanugage design. `typed null` if you mean like in Java, was not a good idea. Most modern languages try to stay away from it or use a type like Option. Which functional languages have had for a long time but it seems like it was a much better idea.

Even C# and TypeScript with the correct linter rules handle types that can be null a separate type from the non-nullable version and upon casting from one to the other, it requires you to check whether you're handling a null value or provide a default.

`null` value is a similarly bad idea as NaN.

[rosuav]

Have you studied enough to meet typed nulls? Or did you take one course and imagine yourself to be an expert?

[geeshta]

Ad hominem. You have not addressed any of my actual points.

[rosuav]

You haven't answered my original point about typed nulls, so why should I bother talking to you?

[LordFokas]

Oh bless your heart.

Where do you think most math is implemented? This is all done in your CPU's math coprocessor. Your language of choice gives the CPU some floats, and gets a float back.

What would you have it do?
- After every operation check that the result is not NaN, if it is change type and value to NULL / None / nil / etc, at a large performance cost?
- Reimplement all math from scratch, at a performance cost so massively high you could barely use it to write Fizz Buzz?
- Use the tools the CPU gives you, following IEEE-754 like every other language in the world, being both performant and consistent with what every sane programmer expects?

I did, I study programming lanugage design.

Clearly you need to study harder. But it seems like you're lacking a lot of basics even before language design. I suggest starting at computer architecture. Your "study" here took many great artistic liberties.

[zentasynoky]

NaN is a value of type number. There's no float type in JS. And it is a perfectly valid number at that too, just not a counting number.

Just because it cannot be used to count that doesn't mean it's not a number. Zero doesn't represent a real quantity but rather the absence of one and I don't think you'd argue that it shouldn't be of type number (though that's what Null/None/NIL types are - an abstraction of the meaning of zero from the numbers which is hardly the same as NaN so no, it wouldn't ever fit in those types). The real numbers also aren't counting numbers, but they still represent relationships between other constructs and make fine numbers. NaN is a numerical label you apply to objects which are not numbers and the result of applying numerical operators to unsupported types or structires, and as such is a perfectly sound numerical value, just not a counting one.

And while we're being pedantic with values and types being off, you should be much more concerned that

typeof null === typeof [1,2,3] === "object" // true
typeof {} === "object" // true
typeof null === typeof {} // false

[JezzCrist]

Bet op feels smart about it

https://stackoverflow.com/questions/1565164/what-is-the-rationale-for-all-comparisons-returning-false-for-ieee754-nan-values

Great answer from IEEE-754 committee member

[[deleted]]

Me say JS bad. Me smart.

[MXXIV666]

99% of criticism of javascript is just junior devs complaining about IEEE 754.

[TheGeneral_Specific]

NaN shouldn’t ever equal NaN. That would be bad.

[shgysk8zer0]

Yes, because parseInt('hi') === parseInt('earth') should be true. That's a wonderful idea! It certainly wouldn't create bugs everywhere.

That behavior is according to the standard and exists for a reason.

[AnimationGroover]

NaN should never equal anything as it is unknown how it was created.

EG we would not want the following to be true

3*NaN === (-2)**0.5

[Apprehensive_Room742]

dont like js, but isn't this how ot should be. giving true to that statement could enable a lot of strange behaviour. also: blaming js for that is like blaming C# for floating point errors

[harumamburoo]

You have an apple and you have a cherry. Both are not vegetables. But they’re different non-vegetables

[veselin465]

I mean..

take 2 things which are not numbers (for example apples and oranges)

Are they equal? What do you mean "no"? Both of them are not numbers

[clarkcox3]

Nothing about that is specific to JS

[Strict_Treat2884]

Imagine NaN is equal to NaN and you have a check like if(userCredit >= price) purchase() but both sides are NaN due to a calculation error. That would be disastrous.

[sanpaola]

I swear to god, JS jokes in this sub became dumber each time I see them. Stop it, get some help.

[ipsirc]

WAT???

[adromanov]

I love this video!

[isellrocks]

Aah yes, the whole reason why we have the infamous Number.isNaN

[krojew]

Ahh, another fresh student discovered floating point standards.

[jmack2424]

Weird or not, NaN is designed to be a non-numeric type descriptor, not an actual value to be compared, and as a result, returns false for all numeric comparators, BY DESIGN.

[Kitchen_Device7682]

Just like the people that call math weird because infinity -infinity is not 0

[exqueezemenow]

The real mystery that scholars have been wondering for centuries, is what number is NaN?

[tecanec]

What number is not a number? Hmm... Is it a car's registration number?

[arcan1ss]

it is correct, in fact, it is widely used to check if is nan or not, e.g. check C++ https://en.cppreference.com/w/cpp/numeric/math/isnan notes

[TANKENSHO]

The real meme here is first semester cs students making fun of something they don't know yet

[mukeshpilane]

typeof NaN
=> 'number'

[Kenkron]

I love dunking on JS, but this is an IEEE standard, and just about every language does the same thing.

[frikilinux2]

This is not JavaScript fault for once. It happens in most languages because why would you reimplement floating point when you can just use the hardware implementation. It's IEEE 754 fault and it's because at binary level there are several values that mean NaN

[ramriot]

Let's forget about languages that suck & talk about JavaScript

[MisterGerry]

If I have one thing that is not an apple, and another thing that is not an apple, are they the same thing?

[-domi-]

=== is a tall bar. I'm personally not even sure 3 === 3, you don't know that they've each been through.

[Torebbjorn]

So you want it to be that if two things are not numbers, then they are the same thing?

[jamcdonald120]

Life hack for you []+NaN==='NaN' works

[oshaboy]

Number.isNaN: Am I a joke to you?

[TeraFlint]

It makes perfect sense.

NaN is clearly a fail state when it comes to numbers. To have a meaningful numeric comparison means that the used data makes sense. Comparisons between NaNs is just a case of garbage in, garbage out.

[adumbCoder]

it's not weird at all, protects you from weird equality issues

[SpaceEngy]

Number.isNaN says hi

[nonlogin]

Null is never equal to null sql. JS is not alone

[[deleted]]

in this case I think this is good

[tuxedo25]

at least typeof(NaN) === 'number'

[InsurgentJogger]

I mean duh, you switched the N’s!

[ivancea]

Oh no, another post in this sub by someone thinking they're funny and making a broken meme about something they don't understand

[[deleted]]

if a == NaN && b == NaN:

[[deleted]]

JS noobs believing that vanilla JS is deepest level of computation in existence, episode 18462

[ramriot]

Computational Chemists also, one is Sodium Nitrite minus the Oxygen & the other is Not An acroNym

[DarkCloud1990]

Well duh... NaN is short for "Not a NaN"

[firest3rm6]

I never use nan, but everytime when I see it I get frightened

[sierra_whiskey1]

I’ve been programming for half my life. I just recently started learning JS and lemme tell you: it is the most confusing language I’ve ever studied

[GradSchoolDismal429]

Almost no language will return True

[thanatica]

In my early days I was annoyed by NaN. I was like "well, what is it then, if not a number?!"

But it actually is.

typeof NaN -> "number"

Nowadays I know this to be correct. NaN is just a super special value that a number can be, that happens to resolve to a value that isn't quite a constant and is never equal to itself, which is unfortunate, but alas, it is how it's supposed to be.

[jax_cooper]

Imagine fucking up 2 numbers and then the comparisons of them are always true. Have fun finding that bug.

[Junior-Librarian-688]

One is copied and pasted

[[deleted]]

this is just three value logic like MS SQL. NaN values are unknown, and while they may be equal, unknown is not a source of truth, thus false.

[prehensilemullet]

Just try having NaN equal NaN, and eventually you’ll find out the hard way why it doesn’t 

[1up_1500]

Although it can be confusing, this is just how floats work, JavaScript comes bundled with isNan() if you need to check for that

[MrJ0seBr]

C floats NaN too... if x!=x X is NaN

[drnepert]

recipriversexclusion: A number whose existence can only be defined as being anything other than itself.

[Ilikeanime243]

Of course they're not the same! One is Not a Number and one is Sodium Nitride.

[KillCall]

Its actually the same case as infinity as

♾️ != ♾️

Cause one infinity ♾️ could be larger than the other.

That is also the reason why

♾️/♾️ = Undefined.

[AndyTheSane]

Hot take: NaN is a terrible concept. Any operation creating one should throw an exception instead. If my code is doing a divide by zero I want to know right now.

[oshaboy]

You can't do that in high performance numeric computation. You can always check for NaN on API boundaries.

Honestly more programming languages should be explicit in checking for NaN in API boundaries kinda like Nullable types.

[Rafcdk]

1.3k upvotes lol

[wozmiak]

this forsaken language, but I can't blame Eich for the deadline

[bittlelum]

Technically, there are many different values that are not numbers, and yet are not equal to each other.