
NaN does not mean "I am not a number” - thinker
https://github.com/jashkenas/underscore/issues/406
======
PhasmaFelis
I love the folks getting all snarky and superior at the guy who was foolish
enough to suggest that "Not a Number" should not be a number.

There's probably some cutting insight into programmer culture here somewhere.

------
xupybd
This may be correct, but why name it NaN if its a number. I thought we were
meant to write readable code. Poor naming like this in the specs really does
not help.

~~~
dragonwriter
> This may be correct, but why name it NaN if its a number.

It is definitively _not_ a number in the usual, mathematical sense -- hence
the name, which comes from IEEE 754.

However, the isNumber function doesn't really check if things are numbers, it
checks if they are of the Number type, which, potentially confusingly,
includes things which are not numbers, including the accurately named value
Not-a-Number (NaN).

~~~
xupybd
So it's Not-a-Number but isNumber returns true?

That would imply then that isNumber is named incorrectly. So perhaps isNumber
should read isNumericType?

Most of the time I want to test, is this a number I can use in a normal
mathematical sense. As in, can I use it in subtraction, multiplication etc. I
know now that I should use isFinite and isNumber, but wouldn't it be nice to
have just one well named function for this?

~~~
cypher543
It's consistent with the names of other type-checking functions. isNumber
checks if a value is an instance of the Number class just like isDate checks
if a value is an instance of the Date class. If it were isNumericType, they'd
get questions about why the function doesn't follow the existing naming
convention.

The only reason this is confusing for people is because they aren't familiar
with IEEE 754 floating-point numbers and their representations. But since
floats are used in almost every programming language, it's something that any
programmer _should_ be familiar with. Once they learn exactly what NaN means
in that context, then the confusion should disappear.

~~~
xupybd
I really dislike this sort of reasoning. That its only confusing because you
don't know enough. It's possible to word things in ways that are easy to learn
and lead you to an understanding of the underlying mechanics.

Its confusing because NaN explicitly states not a number. Then the function
explicitly states is number.

However the two are in very different contexts, yet this is not communicated
when using them. It's intuitive to think of a date as a class and there for
the context is implicit in isDate. I don't think this is the case for
isNumber.

I think this is less about people understanding floating-point numbers more
about understanding that a function starting with is implies some form of type
checking.

~~~
dragonwriter
> Its confusing because NaN explicitly states not a number. Then the function
> explicitly states is number.

The problem is that "Number" is the name of a JS data type, and "number" is
the name of a concept, the two don't match exactly, and when you are using
camel-casing for word separation, you can't distinguish the two.

The function "isNumber" checks if the thing it is applied to is a JS Number,
not if it is a number.

------
fpaboim
This discussion is ridiculous. NaN should obviously return true of isNumber,
and probably just indicates you did something funky with your numbers and they
exploded. They're still numbers, you're the one who's at fault (I never really
saw NaN come by on purpose...). It's just that computers can't really
represent some numbers and when that happens you get NaN and as much as you
want languages to read as english or be perfect abstractions sometimes
practical implementations details end up surfacing and theres nothing you can
do.

~~~
xupybd
But there is something we can do. We can make the context clear and resolve
this.

------
personjerry
tl;dr: Guy suggests isNumber(NaN) should be false. But it's true because NaN
is part of floating points as defined by IEEE.

My own interpretation? While programmers shouldn't care so much about this
particular kind of semantics (instead they should understand the theory behind
floats and never have to run into this issue) it might be better just to call
NaNs something else, like "undefined number" or something.

~~~
dragonwriter
> My own interpretation? While programmers shouldn't care so much about this
> particular kind of semantics (instead they should understand the theory
> behind floats and never have to run into this issue) it might be better just
> to call NaNs something else, like "undefined number" or something.

Or, better, call the JavaScript type that represents IEEE-754 Binary64 format
-- which includes the union of three sets (finite numbers in a given range,
two infinite numbers, and two kinds of Not-a-Number values) something other
than "Number".

------
derefr
Isn't this what type systems are supposed to be for?

    
    
        1.0 / 1.0
        => Just 1.0
    
        0.0 / 0.0
        => Nothing

