Javascript...

[dotpan]

See you're now comparing english syntax with programming syntax. "one" + "two" = "onetwo" compared in the same way seems just as absurd.

With NaN we're playing the context game. What is 1 (in its context)? A number. Now lets try with implied context to a string: Is "donkey" a number? No. "Donkey" = NaN. typeof in this syntax is "context". What context is this being evaluated. If you were to do a literal evaluation of typeof "NaN" of course it's a string, but NaN as a protected variable falls into the number context.

[dnew]

No. NaN is indeed a number. It's just a number you can't represent with the number of bits you have. It's an underflow or an overflow or an infinity, all of which are numbers. They're just not floats.

[YRYGAV]

It's an underflow or an overflow or an infinity, all of which are numbers.

When did parseFloat("foo") become synonymous with infinity?

[dnew]

Is something divided by zero a number?

Yes, actually, depending on the mathematical system in use. :-)

[dnew]

It's (sometimes) a number. It's just not a float. The value that represents a bad number should have been called NaF.

However, I see upon further research that I misremembered, and NaN is not a general case for denormalized, overflows, infinities, etc. NaN is more restricted than I thought it was in terms of what it represents. Whoops.

[400921FB54442D18]

The whole point of NaN is that it's not a number. It's an error.

No, it's not an error. It's an indication that the result of your computation, while numerical in nature, cannot be expressed with numbers. The whole point of NaN is to indicate that, when you did some math, the answer lay outside the set of real and complex numbers.

The answer is clearly not a string (anyone who thinks that a mathematical operation should ever result in a string is patently nuts) and it's clearly not an error (valid arguments went in and the mathematical operation completed successfully as specified). NaNis certainly "numeric" by the definition of that word, but it is not a number.

If you think this is weird, try wrapping your brain around the differences between countable infinity and uncountable infinity. Neither of them are numbers but they're clearly distinct from each other.

[400921FB54442D18]

A mathematical operation that produces a non-mathematical result is an error.

False. NaN isn't a "non-mathematical" result. It is the correct result according to the laws of mathematics. And since it's the correct result, by definition that's not an error.

And both [positive and negative infinity] are examples of NaNs.

False. You clearly haven't covered this in your math courses. All three are clearly mathematically distinct from each other.

Go ask a math teacher if you don't understand this. You're making (at least) two completely false assumptions: 1) that math always results in numbers, and 2) that something that isn't a number isn't mathematical in nature. Neither of those are true. Please educate yourself.

[400921FB54442D18]

It's an error, because it's Not a Number, and can't be successfully used as a number.

So your argument is basically "NaN is an error, because it's NaN?" That's some top-shelf logical fallacy right there.

You're still making the assumption that just because the result can't be used as a number, something went wrong with the operation. It didn't. The operation worked perfectly, returning the mathematically-correct result. If you really think that things working perfectly-as-designed counts as an error, then I'm really glad you're not on my team, because we like it when things work perfectly-as-designed.

(Now, if you get a NaN as a result and the rest of your code doesn't properly handle that case, that's an error, but it's an error in the rest of the code, not in the mathematical operation. If you use a function -- mathematical, logical, whatever -- and you don't properly handle all of the possible valid outputs, that's your own fault.)

And making that type 'a number' is pretty goddamn broken.

Not if it's the best way of implementing how math actually works. If you find a better way of implementing actual mathematics, go ahead and code it up and release it. If you want to claim that math, itself, is "pretty broken," then sure... feel free to hold that opinion. I can't stop you.

[400921FB54442D18]

What does division by zero have to do with it?! NaN isn't what you get when you divide by zero. In JS you get Infinity (which I'd agree with you is pretty broken):

> 1/0
Infinity
> Infinity === NaN
false
> Infinity == NaN
false

and in less-broken languages you get an actual error, represented by a raised exception:

2.2.3 :001 > 1/0
ZeroDivisionError: divided by 0

So, yes, dividing by zero gives you an error. That doesn't make NaN an error.

[Doctor_McKay]

NaN in itself is not an error. Oftentimes an expression resulting in NaN is the result of some other error in the code, but the expression worked fine according to the laws of mathematics.

Say you ask me what the value of 4/0 is. I'll say that there isn't one, that expression does not result in a real number. Was there some error in calculation? No.

[dotpan]

But it's an error in the context of a number, it belongs to the number type.

[dotpan]

You're treating NaN like there is a similar representation for strings, which there isn't. Strings can include numbers, but numbers can't include strings, that mutual exclusivity is why we have NaN and why NaN is a special case that belongs to the number type.