NaN does not mean "I am not a number” • Hacker News Board

Re: NaN does not mean "I am not a number”

#11

Post by xupybd » Fri, Jul 11, 2014, 1:14 AM UTC

cypher543 wrote: post #8

xupybd wrote: post #5

Earlier quoted context omitted.

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 th…

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 n…

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.

Re: NaN does not mean "I am not a number”

#12

Post by xupybd » Fri, Jul 11, 2014, 1:38 AM UTC

dragonwriter wrote: post #7

xupybd wrote: post #5

Earlier quoted context omitted.

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 th…

> So it's Not-a-Number but isNumber returns true? NaN is not a number (the concept) but it is a Number (the type). > That would imply then that isNumber is named incorrectly. Arguably, it is Number (the type) that is named incorrectly (a type called Number that includes a value called Not-a-Number seems problematic.) Maybe "Number" should be called "MaybeNumber". And, perhaps more importantly, the fact that JS doesn'…

We just need a way to indicate if the method is checking the type or the value.

Re: NaN does not mean "I am not a number”

#13

Post by derefr » Fri, Jul 11, 2014, 2:06 AM UTC

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

    1.0 / 1.0
    => Just 1.0

    0.0 / 0.0
    => Nothing

Re: NaN does not mean "I am not a number”

#14

Post by dragonwriter » Fri, Jul 11, 2014, 2:10 AM UTC

xupybd wrote: post #11

cypher543 wrote: post #8

Earlier quoted context omitted.

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 n…

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'…

> 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.

Re: NaN does not mean "I am not a number”

#15

Post by dragonwriter » Fri, Jul 11, 2014, 2:13 AM UTC

cypher543 wrote: post #8

xupybd wrote: post #5

Earlier quoted context omitted.

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 th…

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 n…

> The only reason this is confusing for people is because they aren't familiar with IEEE 754 floating-point numbers and their representations.

NaN is part of IEEE 754, but it is not a number.

The reason people are confused is because the JS datatype name has a small but critical disconnect from what the values it contains are.

Re: NaN does not mean "I am not a number”

#16

Post by fpaboim » Fri, Jul 11, 2014, 4:03 AM UTC

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.

Re: NaN does not mean "I am not a number”

#17

Post by twiceaday » Fri, Jul 11, 2014, 6:10 AM UTC

fpaboim wrote: post #16

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…

1%0 is not found on the number line. It's not a number.

Re: NaN does not mean "I am not a number”

#18

Post by wlievens » Fri, Jul 11, 2014, 7:37 AM UTC

fpaboim wrote: post #16

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…

> I never really saw NaN come by on purpose

We use NaN for masking in image processing, for instance for filtering out defective pixels. If a pixel has value NaN, it is ignored across the board.

Re: NaN does not mean "I am not a number”

#19

Post by wlievens » Fri, Jul 11, 2014, 7:40 AM UTC

personjerry wrote: post #9

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.

As dragonwriter has remarked above, the type "Number" includes stuff that isn't a number. That's a bit absurd, it's like having a value "Red" for a "Color" type.

The type should obviously have been called Float or some variant of that, and the type identification function isFloat.

Re: NaN does not mean "I am not a number”

#20

Post by xupybd » Fri, Jul 11, 2014, 11:31 AM UTC

fpaboim wrote: post #16

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…

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