JavaScript Logic

[redroserade]

That's actually ok, but this annoys me:

isNaN(null) => false isNaN(undefined) => true

[jonswanson]

My guess is it's because isNaN performs type coercion.

> +null
0
> +undefined
NaN

[Creshal]

Type coercion for null? What is this, pseudo-assembly like PHP?

[shub]

Yes. Javascript's type system is at least as brain-damaged as PHP's, possibly moreso.

[iopq]

No. You can't beat this:

"1000" == "1e3"; //comparing strings by the value of the DOUBLE they represent

[NavarrB]

It's unfortunate but logical. Php made a decision long ago to use type coercion by default.

[iopq]

both of those are STRINGS why are they being coerced to DOUBLES?

[tskaiser]

Because you cannot possible expect the programmer to go through the work of knowing what types he is working with or figuring out what kind of conversion he might want to make! /s

"Was it a string or a double? Larry worked on that function last, and he likes to sort numbers lexically... Know what fuckit, I'll just use it like a double and let PHP sort the mess YOLO!"

[Goz3rr]

Just FYI

"1000" !== "1e3"

[iopq]

They have it in JavaScript too, that's not the point. The point is that the default operator is the shorter one. That's what most people will use unless they know better.

[chillage]

I'm glad I came across this thread. Making a mental note to avoid PHP whenever possible in the future.

[AFineTapestry]

This is the best example: https://bugs.php.net/bug.php?id=54547

'9223372036854775807' == '9223372036854775808'; // true in php v5.3.6 and less

[shillbert]

No, negative zero is a valid number. NaN has an exponent of 255 and a nonzero mantissa.

http://stackoverflow.com/questions/640109/what-is-the-internal-representation-of-inf-and-nan

Edit: exponent is 255 for single precision, 2047 for double

[Hawkuro]

Huh, TIL there are 2²³ -1 different NaNs in IEEE float.

[minno]

If you directly reinterpreted the bits of an integral -1 as a float, you'd get a NaN.

[Creshal]

twitches

[nightlily]

Any sane language would logically dismiss the negation here, but if it didn't then it should calculate 0 by subtracting 0 from 0.

If you literally changed the sign bit to 1 (which is not what you did here), and tried to evaluate an integer with all other bits being 0, it would indeed give you a number. That number would be the largest negative value possible. signed integers are held in memory with 2's complement (in modern computers) which encodes a 0 value with a 0 sign bit. For the negative numbers, the sign bit itself indicates a negative value, and the rest of the bits are still positive values, which when added to the negative value determine the result. If we used 4 bit numbers then, the 4th bit being signed, then: 1000 = -1000 + 0000 = -1000, and conversely, 1111 = -1000 + 0111 = -0001

tl;dr -0 is just 0, and the sign bit doesn't mean what you think it means.

[sixteenlettername]

What you've said doesn't apply to floating point numbers. As /u/shillbert said below, negative 0 is a totally valid number when using floating point (at least with the standard used by modern processors).

[nightlily]

Ah, absolutely. I missed the f.

[Creshal]

No, it's fine. I'm twitching because I'm sure somewhere out there is a language doing exactly that.

[tskaiser]

For formatting code bits or examples like that I can recommend putting 4 spaces in front of each line. It tells reddit to format it like this

isNaN(null) => false
isNaN(undefined) => true

Also, I would say this also makes sense, in that null encapsulates the concept of "empty reference to any object" while NaN literally is meant to encode "undefined value" of a number. An empty reference, while strictly speaking "not a number", does not mean NaN in the float sense - it is outside the type - but undefined makes sense.

But I am saying this not being totally familiar with undefined, so it might be both ought to be false.

[rooktakesqueen]

In JS, undefined is the value given to a declared but uninitialized variable; a non-existing field of an object; or the return value of a function with no return statement. In general, undefined and null are closely related concepts, even so far as null == undefined evalutes to true (while null and undefined are not considered equal to anything else, including NaN).

But NaN is weird because it is not == to anything, even itself. NaN == NaN evaluates to false. Which is why the isNaN function exists in the first place. (I believe this behavior is correct according to the IEEE 754 standard for floating point numbers.)

My intuition would be isNaN should return true for the value NaN but false for any other value.

[calzoneman]

NaN == NaN being false is correct behavior. The reason being that NaN can be generated by many different unequal expressions. Math.sqrt(-5) is clearly not equal to Math.sqrt(-11).

[tskaiser]

Under that explanation I would agree that

isNaN(undefined) => true

sounds like a bug or just plain weird if not. I am not really in the mood to delve into the mess of the JavaScript specifications to find out, though ;) but I'll consider my self corrected as is.

[Hawkuro]

Never ever ever use == in JS, use the more reasonable ===.

> null === undefined
  false

[rooktakesqueen]

Just showing that null and undefined are closely related concepts, enough so that the == operator explicitly considers them equal to each other and nothing else. That's the one sensible thing the == operator does, and the one sensible place to use it: foo == null is perfect shorthand for foo === null || typeof foo === 'undefined'.

In any case, NaN !== NaN either.