# Comparison operators

Credits: illustration by unDraw

# 1. Why NaN isn't equal to NaN?

Example:

`NaN === NaN; // falseNaN == NaN; // false`

## Explanation

This behavior is specified by ECMA-262 in Strict Equality Comparison and Abstract Equality Comparison sections. In both comparisons, wheter strict (`===`) or not (`==`), if any of the operand is `NaN` the result is `false`. The pseudo code mentionned is as follows :

`1. If Type(x) is different from Type(y), return false.2. If Type(x) is Number, then  1. If x is NaN, return false.  2. If y is NaN, return false.`

This is inherited from IEEE 754, the IEEE standard for floating-point arithmetic, which states that any operation performed on `NaN` should yield a false value or raise an error.

# 2. Why [] == ![] but [] == []?

Example:

`[] == [] // false[] == ![] // true[] === [] // false[] === ![] // false`

## Explanation

With Javascript, comparing empty arrays (or any arrays) only returns true when the array is compared to itself. In the first example, two new empty arrays are created and compared. Since both values before and after the equal signs are implicitly declared and not referencing the same object, the comparison returns false.

A different behaviour in Javascript is that an empty array is considered a truthy value, thus converting an empty array to a boolean value returns `true`. In the second example, an empty array is compared to `![]`, which resolves to `false`. For the comparison, the first empty array is converted to its primitive value, which is an empty string (`""`). An empty string is considered a falsy value. The result is that a falsy value is compared to `false`, which returns true.

For the third example, two empty arrays are again implicitly declared and referencing two different arrays. This returns `false` as the references are checked are not equal.

The final example does a strict comparison against an empty array, thus an `Array` type, and `![]`, which once again resolves into `true`. Doing a strict comparison first checks both values' types, which are `Array` and `Boolean` here, and returns `false` if not equal.

# 3. Does the new String(...) makes any sense?

Example:

```js new String('foo'); // String {"foo"} typeof new String('foo'); // 'object' 'foo'; // 'foo' typeof 'foo'; // 'string'

//but...

new String('foo') == 'foo'; // true

`TODO: explanation​## 4. How does x < y < z / x > y > z works?​> Example:```js1 < 2 < 3; // true3 > 2 > 1; // false`

## Explanation

TL;DR:This is javascript way of evaluating above expressions and the reason for such wierd results

Generally the expression 3>2>1 is expected to return true since it is mathematically correct. But as javascript is a weak typed language, the evaluation of the above expression is done a bit differently. So lets break the evaluation down to 3 fundamental steps 1. ### Operator Precedence There are 2 operators(>,>) used in this expression (3>2>1) which have the same precedence. So the expression is evaluated from left to right as per Operator precedence table 2. ### Evaluation of left most expression The left most expression in `3>2>1` is `3>2`. Javascript evaluates this expression and returns `true` as 3 is greater than 2. Hence we are left with the expression `true>1` 3. ### Implcit conversion Javascript now evaluates the left out expression i.e., `true>1`. As Javascript is weakly typed language, instead of throwing an error for operands of different types , it implicitly converts `true` to `1`. So the expression is transformed to `1>1` which is obviously false. Hence the value is returned as false.

These are the steps that are followed to evaluate the expression and are the main reason for the weird results like the below ones

`3>2>=1 //true0<3<2 //true`