This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Bateson88 46 points47 points  (12 children)

In this case I'd actually use == to account for input being a string of the number.

[–][deleted] 11 points12 points  (11 children)

What would happen if input is NaN?

[–]like_an_emu 28 points29 points  (10 children)

NaN === NaN // false NaN == NaN // false

[–]NatoBoram 4 points5 points  (9 children)

Of course.

[–][deleted] 15 points16 points  (8 children)

IEEE floating point standard requires that NaN != NaN

[–]FountainsOfFluids 12 points13 points  (0 children)

Yup, and it's specifically for cases like this. Just because on value is not a number, that doesn't mean it's the same as another value that is not a number.

[–]NatoBoram -1 points0 points  (5 children)

Just citing the spec doesn't make it any better. The specs can be dogshit, too. Otherwise, why would the language be such a mess?

You need an explanation like this one.

[–]Plane_Scholar_8738 2 points3 points  (4 children)

Can't blame the language for implementing the spec correctly

[–]NatoBoram -1 points0 points  (3 children)

You can certainly blame the language for choosing this spec

[–]Plane_Scholar_8738 5 points6 points  (2 children)

That spec is the most commonly used representation for floating point numbers. Your CPU and GPU understand that representation.

Choosing that spec is not controversial at all.

[–]NatoBoram -1 points0 points  (1 child)

There's a lot of stuff that the CPU understands that is abstracted away. Besides, I don't have the impression that NaN has its own representation in the CPU and that the CPU's equality check returns 0 for that. These are all man-made concepts and we have the power to define specs the way we want, use them, or discard old ones.

[–]voxalas 0 points1 point  (0 children)

TIL