Вы когда-нибудь сталкивались с JavaScript-объектом NaN? Вы тратите часы на переполнение стека (Окей, немного преувеличения), пытаясь понять, почему NaN === NaN или NaN == NaN принимает значение false?

Если да, то вы уже знаете, что NaN - единственный объект JavaScript, который возвращает false по сравнению с самим собой.

Для тех, кто не знаком с JavaScript, NaN (Not a Number) - это объект, который является возвращаемым значением, когда функции Math не работают.

(Math.sqrt(-1)); 
//or when a function trying to parse a number fails 
(parseInt("blabla"))

Для сравнения, различные оценки NaN и результатов выглядят следующим образом.

NaN === NaN;        // false
Number.NaN === NaN; // false
isNaN(NaN);         // true
isNaN(Number.NaN);  // true

function valueIsNaN(v) { return v !== v; }
valueIsNaN(1);          // false
valueIsNaN(NaN);        // true
valueIsNaN(Number.NaN); // true

Но что, если я скажу вам, чтоtypeof NaN это 'number'

Так что я был одним из тех любопытных умов, которые искали ответ, когда я натолкнулся на NaN в первые годы работы над JavaScript. И единственный ответ, который я нашел, был: «Потому что JavaScript так говорит». Для 13-летнего мальчика, только начинающего свой путь в святая земля программирования, которая в то время была удовлетворительным ответом. С тех пор каждый раз, когда мне нужно было протестировать NaN, я использовал isNaN, не понимая его полностью, потому что «JavaScript так говорит».

Сегодняшний день - я работал над проектом AI чат-бота React-Node.JS на выходных, а затем случилось то, что простая библиотека компонентов реакции, которую я построил в прошлом, внезапно начала выводить NaN (простая ошибка синтаксического анализа в моем компоненте библиотека).

Но они мало что знали. Теперь, когда я вмешался в JavaScript, это большое разнообразие фреймворков и библиотек на протяжении более 10 лет, и, создав несколько библиотек, я был готов раскрыть тайну NaN. Поэтому я решил надеть шляпу Шерлока Холмса (вместе с моим поддельным британским акцентом) и углубиться в суть JavaScript и даже дальше в искусство информатики.

Причина такого поведения кроется в истории NaN.
NaN были введены стандартом IEEE для арифметики с плавающей запятой (IEEE 754) где-то в 1985 году вместе с такие величины, как бесконечность, являются стандартом для недопустимых результатов арифметической операции. NaN представлены как поля, заполненные единицами в памяти компьютера. До стандарта IEEE программисты часто использовали специальные значения для представления неопределенных значений, но не было гарантии, что они будут обрабатываться последовательно или правильно.

Теперь рассмотрим операцию сравнения двух значений a и b, такую, что

a == b может иметь 4 возможных результата.

  1. а больше, чем b
  2. а меньше, чем b
  3. a равно b
  4. a и b неупорядочены, если любое из значений равно NaN и, следовательно, не может считаться равным (это также имеет место, когда a и b являются NaN) в соответствии с IEEE 754

Отсюда и причина, по которой любое прямое сравнение вернет false, а также причина, по которой === также вернет false.

Тайна была разгадана.

Элементарно, мой дорогой Ватсон.