JS shitters will defend this
JS shitters will defend this
Other urls found in this thread:
github.com
twitter.com
"b" + "a" + +"a" + "a"; // -> 'baNaNa'
Regardless of how much of a busted language JS is, there's no reason to omit "NaN === NaN" in your image as it would have revealed the underlying principle. Bad thread. Fuck you.
cope
I don't like JS either but this makes sense from a common sense perspective, and an IEEE float perspective.
sdfsdf is not a number
sdfsdf is not the same as everything else that's not a number
isNaN detects any value that isn't a number
"==NaN" isn't something you can/should do in any language using floating point.
seethe
>sdfsdf is not a number
>sdfsdf is not the same as everything else that's not a number
A common sense perspective would lead me to think ===NaN should test whether it is not a number. NaN is a type so equality tests with a type should test whether a value is that type, shouldn't it?
use Number.isNaN()
it doesn't convert
'a' is not a number
'b' is not a number
'a' is not 'b'
This violates what === should do
It's not JS's fault, it's the way IEEE math works.
github.com
>Following the definition of NaN from the IEEE:
>Four mutually exclusive relations are possible: less than, equal, greater than, and unordered. The last case arises when at least one operand is NaN. Every NaN shall compare unordered with everything, including itself.
Use Typescript you brainlet
Dilate
you can't spell underlying without lying
rent free
>NaN === NaN
>false
How can 'herp' === NaN and 'derp' === NaN but 'herp !== 'derp'?
=== NaN should never be used
NaN is never equal to NaN, in any properly implemented language. And probably not even in PHP.
Yet another dumb crossboarder brainlet incapable of reading up on IEEE floats and their standard behaviour in JS
verb
oh no code golf tier, never used, UB code doesn't comply with your standard output that's compared with nothing else because only js has the functions for this, what a bummer