преобразование типов при сравнении

[Whatsername]

trace(0 == "0"); // true
// Это происходит благодаря приведению типов: строки "0" к числу 0.
trace(0 == undefined); // false
// undefined преобразуется в число 0, почему же тогда false?
// Объясните идиоту, пожалуйста.

[Nео]

потому, что undefined при преобразовании к числовому типу дает NaN

[netstuff]

читаем хелп

Undefined data type
The undefined data type has one value, undefined, and is automatically assigned to a variable to which a value hasn’t been assigned, either by your code or user interaction.

The value undefined is automatically assigned; unlike null, you don’t assign undefined to a variable or property. You use the undefined data type to check if a variable is set or defined. This data type lets you write code that executes only when the application is running, as shown in the following example:

if (init == undefined) {
trace("initializing app");
init = true;
}

If your application has multiple frames, the code does not execute a second time because the init variable is no longer undefined.

всё понятно? юзай NULL :D

[Whatsername]

Я ориентировался на это

trace(Number(undefined)); // 0

[iNils]

Ну мало ли, что trace выводит.
Вот пример:
f = 1.000000000000001;
trace (f); // 1
trace (f - 1); // 1.11022302462516e-15, а ожидалось мной 0

[Whatsername]

Хм, я не назначал undefined ни свойству, ни переменной, разве не так?
По любому,
trace(null == 0); // false
// but
trace(Number(null)); // 0

[netstuff]

я уже теряю нить этого флейма, но тем не менее:

согласись, что присваивание переменной
trace(null == 0); // false

и вызов функции возващающей какое-то значение
trace(Number(null)); // 0

это не одно и тоже. тем более в разрезе trace()

[Nео]

Я ориентировался на это

trace(Number(undefined)); // 0
trace(Number(undefined)); // NaN
trace(Number(null)); // NaN

[iNils]

MX
trace(Number(undefined)); // 0

MX 2004
trace(Number(undefined)); // NaN

[Whatsername]

согласись, что присваивание переменной
trace(null == 0); // false

Не хочу прослыть пуристом-недоучкой, но где тут присваивание переменной?
И это не флейм (я очень благодарен тебе и другим людям, что учавствуют в этом треде).
Если долго медитировать можно предположить, что null и undefined разрешаются в NaN при приобразовании в число, так? А как это можно проверить?

[netstuff]

Не хочу прослыть пуристом-недоучкой, но где тут присваивание переменной?

прошу прощения, что-то я напутал :confused:

[iNils]

Цитирую Нокса
trace(Number("A") == Number("A")); // false

trace(Number(undefined) == Number.NaN; // false

объяснение простое:

NaN - (по фомату IEEE double) это значение числового типа float double такое что его экспонента равна 2047 а мантисса отлична от нуля. т.е. таких чисел - много. какое именно число получится в качестве NaN в каждом конкретном случае - неизвестно.

из этого вытекает то, что нельзя сравнивать результат операции (значение переменной) с константой Number.NaN чтобы определить является ли этот результат числом или нет. надо пользовать глобальную функцию isNaN, без вариантов.

a = "test";
trace(Number(a) == Number.NaN); // false
trace(isNaN(Number(a))); // true

[Whatsername]

iNils, сорри за навязчивость, но все равно не могу понять как проверить, что Number(null) это в действительности NaN.

trace(isNaN(undefined)); // false
trace(isNaN(null)); // false

А ведь если бы undefined и null приводились к числовому типу как NaN, это давало ответ на мой первый вопрос: почему 0 == undefined дает false.

[Nео]

trace(isNaN(Number(undefined))); // true
trace(isNaN(Number(null))); // true

[Whatsername]

Nео, речь идет об AS 1.0 для Flash MX.

[Nео]

сорри... пропустил! :rolleyes:

[Whatsername]

// зря удалил только что написанное сообщение.
В AS 1.0 for Flash MX эти операции приводят к false. Вот.

[Nirth]

востановил сообщение

[iNils]

undefined неопределенное значение, 0 - определенное, даже конкретное число :)
поэтому 0 == undefined дает false.

[Whatsername]

Операторы "==" и "!=" перед сравнением преобразуют операнды к одному типу, отдавая предпочтение числовому.
Если undefined преобразуется к NaN, что мы пока не смогли подтвердить - сравниваются 0 и NaN.
Но если undefined преобразуется к 0 (что мы пока только и видели), то сравниваются 0 и 0. Почему результат такого сравнения false - вопрос, мучающий меня почти сутки.

[iNils]

Колин МУК:

Равенство для элементарных типов данных.

undefined:
Если оба операнда undefined или один операнд undefined, а другой null, резултат true; в противном случаи резултат false

null:
Если оба операнда null или один операнд null, а другой undefined, резултат true; в противном случаи резултат false

Равенство и преобразование типов данных
Если типы операндов разные, интерпретатор осуществляет перед сравнением преобразование типов. Вот правила, которым следует интерпретатор:
1. Если оба операнда имеют одинаковый тип, сравнить их и возвратить результат. (Если null сравнивается с undefined, возвратить true)
2. Если один операнд представляет собой число, а другой - строку, преобразовать строку в число и вернуться к шагу 1.
3. Если один операнд булев, преобразовать бедево значение в число (true = 1, false = 0) и вернуться к шагу 1.
4. Если один операнд предстьавляет собой объект, вызвать метод valueOf () объекта, чтобы преобразовать его в элементарный тип. Возвратить false, если это невозможно. В остальных случаях вернуться к шагу 1.
5. Возвратить false, если на предыдущих шагах не получен допустимый результат.


В твоем случаи, выполняется пункт 5.

[Nео]

Может быть в MXе операторы "==" и "!=" не преобразовывают undefined к числовому типу, потому что trace(0 == Number(undefined)); // true
Вообще странно все это...

[Whatsername]

iNils, спасибище!

Это объясняет и результат сравнения undefined с пустой строкой как false.
Оч клева! И слезы умиления подкатывают к горлу.

Респект и поклон всем кто участвовал. Большое спасибо.

[Whatsername]

Может быть в MXе операторы "==" и "!=" не преобразовывают undefined к числовому типу, потому что trace(0 == Number(undefined)); // true
Да, очевидно, в операциях нестрого сравнения до преобразования undefined в числовой тип данных дело не доходит.

Судя по последовательности работы интерпретатора, данной Муком, и любезно приведенной iNils - это именно так.