I'm really trying to give js a chance. I really wanna get this front end done. But this is just Bullshit.

NaN is still a number. It's a result of a combination of numerics.
Now, this result can come from everywhere, therefore, NaN != NaN because 1/0 is not the same as 5/0.

Exactly what @groxx and @nitwhiz said.

"Wow this language is so bad. Like just look at this thing you wouldn't actually do ever!"

Hey look, another js rant where the author turned out to be plain wrong.

It's like C again.
No exceptions but errors you have to check for instead.

Only in C they're at least documented..

@inaba But in fact, I had to do this thing and it gave me a fucking headache.

@theuser Well fucking excuse me that my opinion about this being bullshit is wrong. Having an opinion only seems to good when it's standardized.
https://stackoverflow.com/questions...

@nitwhiz huh? If it doesn't throw an exception x/0 is Infinity and it doesn't matter what it was previous to that

@Awlex JS conforms to IEEE 754, and it states that any number (except 0 which isn't a number) which is divided by zero, equals Infinity. In addition, IEEE 754 states that certain invalid mathematical operations (like 0/0) equals NaN.

@LinusCDE https://developer.mozilla.org/en-US...

@theuser But we are programmers. Not matematiaians.

If something doesn't work it should say so and not continue to work.
I don't regard NaN as proper answer since only few would check for NaN.
Saying so is throwing an error.

Also NaN (not a number) being of type Number isn't helpful either.

@theuser That part was above the stackoverflow comment I shared, so I know the reason why. But just like the comment, I strongly disagree with that decision/standard.

@Awlex a better analogy would be:

@highlight
parseInt('foo') === parseInt('bar')

// in this situation what would you expect the value to be? It's not a number by type but by value it most probably not the same.

// instead, what you want to achieve is checking the type

typeof parseInt('foo') === typeof parseInt('bar')

@bioDan 'foo' and 'bar' a processed by parseInt and the Results are both NaN. The return value is all that matters to me, because that's why I called the function in the first place.
For example, if I applied the function f(x) = x^2 it should not matter if I applied it on 5 or -5. The result is 25.

Edit: Yes, I accidentally replied to the bot

@Awlex thats fair, but if you pass your function a string, you'll get a NaN since you dont know how to parse that string. The result is surely a number. But parse them as a Hexadecimal, Binary or any other numerical representation you may get same results but with different interpretation.

In this case, both results have a value of one, but they arent equal.

@highlight
0x1 === 5&1
0x1 == 5&1

@bioDan The interpretation doesn't matter. Why should I care about how the function(s) interprets values, if I just want to compare the raw results.
That code snippet also suggests that. Both sides return 1 therefore it's true and it doesn't matter what the arguments are. I just want to compare the results.

@Awlex the code above returns 0 which is interpreted as false

@bioDan That's because the & operator is applied to the result of (0x1 == 5), which is obviously false
If you encapsulate it correctly like 0x1 == (5&1) it returns true

@Awlex nice catch, i guess it wasn't a good analogy after all.

@bioDan Could have happened to everyone. Though it threw me off that a comparison yielded a number. I mean, we're not programming C here 🤣

@Awlex You wouldn't. You would check weather or not something is not a number https://repl.it/repls/...