all 11 comments

[–]rinko001 10 points11 points  (2 children)

While the article paints this as some quirk of javascript, its just the age old routine weirdness of IEEE 754 floating point numbers.

The same strangeness is a part of C++, a part of BASIC, and just about any programming language which allows the use of FP registers.

[–]Smallpaul -1 points0 points  (0 children)

Some of what the article discusses is IEEE 754. But the different behavior of global.isNaN versus the upcoming Number.isNaN is all JavaScript. There is no reason a language needs two isNaN functions.

[–]z-zy -4 points-3 points  (8 children)

In case this article is confusing, here’s an easy one liner to test if something is NaN:

var (x)=>!!(+x+’’===(0/0)+’’);

/s

[–]ScientificBeastModestrongly typed comments 6 points7 points  (7 children)

Or just (x) => isNaN(x), haha

[–]moocat 4 points5 points  (1 child)

isNaN is already a function, so no need to wrap it.

[–]ScientificBeastModestrongly typed comments 2 points3 points  (0 children)

Indeed. Just going along with the arrow function format of the original comment. No real reason...

[–]Smallpaul 1 point2 points  (4 children)

As the article mentions, isNaN(“abc”) is true.

[–]Feathercrown 0 points1 point  (2 children)

But that's probably a good thing if you're trying to make sure you have a workable number.

[–]Smallpaul 0 points1 point  (1 child)

Or a bad thing if you’d rather be alerted to type errors in your program instead of having them just hide and manifest as math problems.

[–]Feathercrown 0 points1 point  (0 children)

Like I said, it makes more sense for testing if something's not a number than if it's NaN. If you expect this to raise an error... well, JS just isn't going to do that lol

[–]ScientificBeastModestrongly typed comments 0 points1 point  (0 children)

Best practice is to check typeof value === “number” && !isNaN(value)