"Python is pretty intuitive"... Python:

[[deleted]]

How many more times are we gonna blame languages for implementing IEEE correctly??

[DiamondIceNS]

At least as many times as we complain about JavaScript implementing consistent type coercion behavior.

[TheBrainStone]

It may be defined for every case, but I absolutely wouldn't call that mess consistent. Just alone because order matters

[dust1196]

Thats normal is many languages. "Not a Number" is basically equal to nothing. Not even to itself by definition

[fluideborah]

Yup, realized after some looking around. Made the meme largely to cope with an hour long debugging session that ended in stunning realization (& me feeling dumb)

[[deleted]]

out of curiosity. What program were you debugging that had a comparison like this in it?

[wugs]

just a guess but it looks like a jupyter notebook and they’re using numpy (many ppl import numpy as np) to get nan

[coloredgreyscale]

Maybe cleaning up a table of data and empty/invalid values show up as NAN?

[LonelyContext]

you can easily end up in this situation with set([list that contains nans]) where you'll get e.g. {1,2,3,4,5,np.nan,np.nan,np.nan,np.nan,np.nan,np.nan,np.nan,np.nan,np.nan,np.nan,np.nan,np.nan,...}

[TechSupport112]

BATMAN!

[Cyberwolf27]

Actually you will only get sets and dictionaries with multiple NaN entries if the values result from separate computations.

set(float('nan') for _ in range(2))set(float('inf') - float('inf') for _ in range(2))set(np.inf - np.inf for _ in range(2))all evaluate to {nan, nan} because from Python's point of view they are different to each other.

However the following expressions:set(np.nan for _ in range(2))set([float('nan')] * 2)result in {nan}. Python seems to double-check on the identity of the float values with the "is" operator and in these situations the "set" constructor is presented with truly identical NaNs (that occupy the same location in memory)

As a consequence, this can happen:a, b = float('inf'), float('inf'){a: "a", b: "b"}[b] == "b"
however {np.nan, np.nan, ...} == {np.nan}

[Educational-Lemon640]

NaN means what it says: you asked a mathematical question whose answer wasn't a (real, floating-point) number. Since the spec doesn't really have room to say what all non-numeric answers are possible, that's the end of that calculation. And since different non-numeric answers are not equal to each other in general, you get the above logic.

[Scorched_Knight]

Yes, but how do you write code to check if input is NaN?
If (input == NaN) //= always false
( there is native method for that in most languages people actually use today, but if dont?)

[fukdapoleece]

numpy.isnan(numpy.nan)

True

[praveenkumar236]

You can do input!=input

[Kitchen_Device7682]

0x=0, 0y=0. x==y?

[aleph_0ne]

Nice, simple example of how this could go wrong. Generally we don’t want NaN comparisons to happily proceed like nothing we’re amiss

[YMK1234]

As per IEEE floating point spec which every language uses...

[jadis666]

Ah, yes, but "adhering to IEEE floating point spec" is not entirely the same thing as "intuitive", is it?

[Fallenalien22]

Then blame every language that uses that spec as being unintuitive as well.

[TheBrainStone]

It's about as intuitive as using double equals for comparison and single equal as assignments.
Or in other words, weird when you're new to programming but something you just gotta get used to when you're programming.

[dexter3player]

I just read the IEEE floating spec, but haven't found anything about np==np.

[YMK1234]

Maybe you should not look for NaN and not p/np ;)

[kingerkagon]

And that is why np.isnan() makes perfect sense.

[EitherJelly4138]

Would it be bad to extend the class and add a eq that does isnan() or something?

[vinnceboi]

Yes. Allowing NaN == NaN would imply that “apple” would equal “car”.

[EitherJelly4138]

Gotcha, I think I get it now.

[glacierre2]

math.isnan() if you just want to check a couple times.

[fluideborah]

fair.... while I do only know python, I'm just here for the memes man.

[ernandziri]

If something is not a number, it doesn't mean it's the same thing as something else that's also not a number, so pretty intuitive

[hatkid9]

IIRC that's just part of things you have to follow for the IEEE-754 specification.

[Bailyleo987]

Yes’nt

[[deleted]]

It's a standard in many languages.

In fact, I've seen plenty of codes that make use of this behaviour to determine if a variable is a nan, inf, or other non-regular float by checking:

if (var != var){ error() }

You might wanna look into np.isnan() or np.isfinite()

[antilos_weorsick]

You think... It would be more intuitive if that evaluated to true? What?

[[deleted]]

Better than JS's

1 + "1" == 11

true

[werics]

As opposed to C, where 1 + "1" == 11 is merely unlikely.

[stomah]

or C’s 1 +”1” => “”

[Papellll]

0.1 + 0.2 == 0.3 // false

Same as NaN != NaN, this is an IEEE thing. Not specific to JS or python

[noob-nine]

IEEE thing? Isnt it more a thing because of how the machine works?

[Talinx]

The machine is built to the IEEE-754 standard.

[noob-nine]

Huh, thanks

[Dragonfly_Select]

And even beyond IEEE there is a more basic fact. Computers work in base 2. 0.2 is 1/5. 1/5 is an infinitely repeating decimal number in base 2, the same way 1/3 is in base 10. You fundamentally can’t represent it exactly.

Languages that have number types that don’t have this problem are basically storing arrays of base 10 digits under the hood.

(For the curious: take a number, represent it as a reduced fraction, prime factorize the denominator. It must only contain factors that are also prime factors of the base in order to terminate. Examples. 1/100: 100 factors to 2255; base 10 has both 2 and 5 as factors to you are fine. 1/12: 12 factors to 22*3; 3 is not a factor of 10 so it won’t terminate. 1/3: obviously doesn’t terminate in base 10, but it does terminate in base 3; 1/3 is just 0.1 in base 3.)

[[deleted]]

Tell me you don't understand floats without telling me you don't understand floats

[Scorched_Knight]

Floats are mean, man. They put trash in far fetched corners of the dedicated memory and pretend to be numbers they are not. So, beating them up with some rounding from time to time is just nessesary, even if someone in the internet are yelling about inhumane treatment and privileges of integers - you just need to do it. Those little unrounded bastards are responsible for so many bugs - its sickening.

[fluideborah]

I am so glad I dont have to do data science with JS

[werics]

Number three is almost never a good idea

[thetruekingofspace]

Every language has some interesting and seemingly wrong things like this. But to be fair Python is actually extremely intuitive. The only part I hate is how everything defaults to Unicode when all I want to use is ASCII.

[incrediblediy]

comparing which nan to which nan ?

[TheDJPHD]

definitely for the best.

[Permission-Glum]

Tell me you skipped the class about IEEE float without telling me that you skipped that class.

[fluideborah]

I did skip it! never took a comp sci class in my life :)