This document explores some of the more unusual idiosyncracies of the JavaScript language, some of which may trip you up if you're not aware of them.

Following is a list of expressions that are all true (i.e. the result of the expressions is always the boolean value true). Some of the expressions are cute or ironic to look at. Others may just be plain puzzling to the uninitiated. Explanations appear below the expressions...

(7 / 100) * 100 != 7

Because of the way that JavaScript represents floating point numbers internally, the expression (7 / 100) * 100 actually produces the result 7.000000000000001. It's not often that humans are better at computation than computers, but this would be one such occasion.

100000000000000000000 + 1 == 100000000000000000000 - 1

Another artifact of JavaScript's rather weak internal representation of numbers. 100000000000000000000 is represented internally as a floating point number that can be expressed in scientific notation as 1e+20. Given the precision of JavaScript's floating point number representation, 1e+20 + 1 is equivalent to 1e+20 - 1.

typeof null == 'object' && !(null instanceof Object)

This one is a bit hard to explain, especially in light of the fact that the statement typeof new String () == 'object' && new String () instanceof Object is true.

typeof NaN == 'number'

Yeah, so in JavaScript NaN is a special value for the number type. So, the expression is technically correct, if appearing a little contradictory on the surface.

typeof !NaN == 'boolean'

For the purposes of boolean logic, notting NaN produces the boolean value true. This is not to say that NaN is equivalent to the boolean value false, though. One could make the argument that it would be more correct for coercing NaN to a boolean type to produce the result NaB (Not a Boolean), but JavaScript has no such concept of a boolean value that is in the paradoxical state of being neither true nor false, or both, or an indeterminate one.

NaN * 2 != 2 * NaN

Yeah, so this one just seems plain wrong on the surface. Why would swapping the two operands make a difference? Swapping operands in a multiplication, we have been taught, does not affect the outcome. So, then, shouldn't the two sides be equal? The trick comes in the odd behavior in JavaScript that the value NaN is not equal to itself. So, it turns out that both sides in the boolean expression do produce the same result: they both produce the result NaN. But, because NaN != NaN, so the two sides - while having the same value - are not equal.

(NaN != NaN) && !(NaN < NaN) && !(NaN > NaN)

Ok, so if NaN is not equal to itself, then it must be either greater than itself, or less than itself, right? Ummmm, yeah. Well, not really. Even though NaN is not equal to iself, it is also not less than or, conversely, (and by implication) greater than itself. This falls squarely into the category of strange but true. Robert Ripley would be proud.

(NaN && !NaN) != (!NaN && NaN)

So, both NaN && !NaN and !NaN && NaN produce the result NaN. Now, because NaN is not equal to itself, the two seemingly equivalent boolean expressions turn out not to be equivalent - even though they produce the same result. This is kind of a "paraphrasing" of the NaN * 2 != 2 * NaN case.

(1 != NaN) && (1 == !NaN)

Just because 1 is not equal to NaN, it doesn't follow that 1 should equal !NaN. It's just a luck that the subtle underlying logic resembles a simplistic logic in this case. 1 is not equal to NaN because nothing is equal to NaN, but the reason 1 is equal to !NaN is because notting NaN produces the boolean value true, and 1 is equivalent to true in a non-strict equality operation.

isNaN (true) == false

Yeah, so you may have been lulled into thinking that a boolean is not a number. Seems perfectly reasonable, eh? Well, not so fast! The isNaN function coerces its single argument to a number type by invoking the argument value's valueOf instrinsic method. Now, for boolean type values, the built-in valueOf converts the boolean value false to 0 and the value true to 1. At this point, the isNaN function is dealing with a value that has been resolved to a number, so it returns false. Not exactly what you might expect (kind of like life).

isNaN (new Boolean) != (typeof new Boolean != 'number')

This is kind of a restatement of the previous example. While isNaN (new Boolean) produces the result false, typeof new Boolean != 'number' produces the result true.

isNaN (NaN) == !isNaN (!NaN)

So, NaN is definitely not a number, so isNaN (NaN) produces the result true. Now, as shown earlier, !NaN produces the result true. So, isNaN (!NaN) produces the result false because - as also shown earlier - the isNaN function coerces a boolean argument to a number and, therefore, returns false. Now, notting that produces true. So, the two sides of the equality operation are true and equal. But it's not because the "inner" and "outer" nots in the right hand expression "cancel" each other out, or anything quite that simplistic.

isNaN (true) == isNaN (false)

The isNaN function always returns false when receiving a boolean argument, so the both sides of the equality operation are false and, therefore, equal.

isNaN (5) == isNaN (isNaN (5))

On the left side of the equality, the number 5 is being tested for not a number, which unsurprisingly produces the result false. On the right side, there is an extra layer of isNaN. The inner test produces the value false, like the left side. The outer test also produces the value false, because the isNaN function returns false if it is supplied with a boolean argument. So, adding the extra layer of isNaN keeps the value false and both sides of the equality are equivalent.

isNaN (new Number) == isNaN (isNaN (isNaN (isNaN (isNaN (isNaN (isNaN (new Number)))))))

You can extrapolate from the previous example, of course. It really doesn't matter how many layers of isNaN you add to the right side. Value's still gonna stay false.

isNaN (NaN) != isNaN (isNaN (NaN))

Unlike the previous two examples, the same cannot be said for testing NaN for not a number. In this case, the left side produces true, but on the right side the inner test produces true while the outer test then produces false.

isNaN ('5') == false

Hmmmmmmmmmm....... just like you might have thought that a boolean was not a number, you might also have thought that a string is not a number. Once again, because the isNaN function invokes the valueOf instrinsic method on its argument to coerce a number, the string '5' is successfully coerced to the number 5, and so isNaN ('5') returns false.

isNaN ('five') == true

Not all strings are created equal. You may have been taught that five is a number, but JavaScript doesn't think so. Apparently, nobody taught JavaScript to read English. Coercing the string value 'five' to a number produces the value NaN, which - while not equal to itself - at least tests true for not being a number.

isNaN (!'a number') == false

Ok, so this one is just trying to be too cute for its own good. It says quite emphatically !'a number', so shouldn't JavaScript pay attention and oblige by testing true for not a number? Well, that's about as ridiculous as expecting that the expression isNaN ('I am a number, damn you') should produce the result false. As it turns out, notting any non-empty string produces the boolean value false, because a non-empty string is considered equivalent to true. Now, as shown earlier, the isNaN function tests false for any boolean argument, because the boolean argument is successfully coerced to 0 or 1.

isNaN (!!'a number') == false

Yeah, so don't think that adding another not before the !'a number' will change the outcome. You're still supplying a boolean argument to the isNaN function. You could also express this as isNaN (!'a number') == isNaN (!!'a number').

(null + null == 0) && (0 + 0 == 0) && (null + null != null)

So, if null + null is equal to 0, then null seems like it's being treated as 0. So, why isn't null + null equal to null? After all, we know that 0 + 0 is equal to 0. What's going on? Simple. The value null is coerced to the number value 0 when used in a numerical operation (such as summing), but it is not coerced when involved in an equality test. The value 0 is not considered equivalent to null.

(0 != null) && (!0 == !null)

As shown earlier, the value 0 is not considered equivalent to the value null in equality tests. However, notting both 0 and null produces the result true. So, while 0 is not equivalent to null, !0 is equivalent to !null.

(+null == +false) && (null != false)

Similar to the previous example, both null and false resolve to 0 when coerced to a number, but are not considered equivalent when compared to each other in an equality type operation.

true == false + 1

Adding 1 to false makes it true? Well, actually, adding 1 to false first coerces false to the number 0 and then produces the result 1 upon adding 1. Now, 1 is considered equivalent to true when involved in an equality operation.

(typeof true == 'boolean') && (!typeof true == false)

Well, it's obvious that the type of the value true is 'boolean'. Now, 'boolean' is a string value, and notting any non-empty string produces the result false, so !typeof true gives you false.

typeof new Boolean == 'object'

This just doesn't seem to make sense, unless you understand what's going on. You might be tempted to think that typeof new Boolean should give you 'boolean'. As it turns out, the type of value that is created using JavaScript's Boolean core object is not the same as the type of a variable assigned with a simple boolean value. When using the Boolean core object to construct an object, you get just that: an object, and not a primitive boolean value.

typeof !new Boolean == 'boolean'

To add irony to the mix, if you not an instance of the Boolean core object and then get the type of that result, you then get 'boolean'. On the surface, it may be strange to look at. Basically, notting any object in JavaScript produces the result false, which is a boolean type value, so typeof !new Boolean is 'boolean'.

typeof typeof undefined == 'string'

So, the inner typeof operation produces a result that is a string, even if its value is 'undefined'. Therefore, the outer typeof operation produces the result 'string'.

typeof window.defined == 'undefined'

So, this is not guaranteed to always be the case, but it's a good bet that the window object doesn't have a property defined called defined. So, it looks like a contradiction, but it's about as weak an apparent contradiction as saying var number = 'string'.

typeof (window.undefined = 'defined') == 'string'

If you want to just get mad with trying to confuse the issue. Nuff said.

(typeof function () {} == 'function') && (typeof function () {} () == 'undefined')

So, naturally the type of an empty anonymous function is 'function'. But, if you add parentheses right after the empty function declaration, then you are essentially calling the function immediately after declaring it. Because the function is empty, it returns the result undefined, the type of which is the string 'undefined'.

(Infinity * 0 != 0) && (Infinity * 0 != Infinity) && (Infinity * 0 != NaN)

So, what exactly do you get when you multiply infinity by zero. You may initially think you should get zero. Not so. Do you get infinity? No. Do you get NaN? No? Then what?!?!? Infinity multiplied by zero is not equal to anything then? Kind of. So, actually, you do get NaN. And, as shown earlier, NaN is not equal to itself, so Infinity * 0 != NaN is true.

!new Boolean (false) == false

Seems like when you not false you should get true. Problem is, in this case you're not notting the primitive value false but an instance of JavaScript's Boolean core object instantiated with the value false. Notting any object in JavaScript produces the boolean value false. This behavior would appear to make the Boolean core object less compelling, since an instance of this object is not interchangeable with a variable set to a primitive boolean value.

	"uize" is the traditional Scottish spelling of the word "use".
	"UIZE" is the call sign of the Russian Federation ship BESSTRASHNYY, a rescue and salvage vessel built around 1963.
	Ironically, the bit.ly short URL http://bit.ly/UiZe links to an article about interceptors in Flex.