таки чему оно равно? a = Double.NaN != Double.NaN даст true или false? Вообще говоря NaN - это специальное значение, сравнивать по которому величины бесмыссленно. Можно только проверить, был ли результат операции NaN или нет. В ECMA Script для этого имеется специальная функция на топлевеле - isNaN(val:*):Boolean
Double.NaN != Double.NaN == true У меня своя специфика - Double обернут другим типом (так надо) Значение этого типа может быть пустым - в ToString() должно вернуться String.Empty Для этого в некоторых ситуациях создавал объект, пихая в поле Double Double.NaN
Что не понимаю - как это значение может вообще получиться использовать практически.
В прочем, по моей теме давно понятно, что от Double надо уходить
В языках с динамической типизацией NaN используется для провеки операций, в которых может быть получен нечисловой результат.
Например в JS\AS при выполнении операции var a = Number("shut up") на выходе получится isNaN(a) = true, т.к. конвертнуть строку в число не получилось. И все дальнейшие попытки использовать это значение в операциях будут приводить к NaN результату. Эксепшен в данном случае не генерится.
В языках, где числовые значения не являются чистыми объектами (т.е. то, что называется "примитивные типы"), для проверки на инициализацию значения используется сравнение c undefined - если переменной не было присвоено значение, то там вместо значения или NaN будет undefined (а не null, как иногда ошибочно полагают).
И да, еще раз - напрямую с NaN ничего не сравнивают. Только через isNaN или его аналог. Т.к. один результат ошибочной конвертации вообще говоря не равен другому.
Меня что удивляет В C# мне известен только один способ присвоить NaN переменной Double d = Double.NaN или Double d = Double(Double.NaN) Конверсии производятся либо операторами приведения типов (либо success либо exception), либо (если из String) через Double.Parse(..) / Double.TryParse(..). При этом если значение будет записано - оно будет корректным.
Почему в этой ситуации не сделать так, чтобы Double.NaN был == Double.NaN мне не очень понятно. Хотя какой-то сакральный смысл наверное есть.
Если есть, то пользуйся) Кстати еще неопределенности должны порождать NaN, например Number.POSITIVE_INFINITY/Number.POSITIVE_INFINITY в AS дает NaN. И, NaN == NaN тоже false
Reply
У меня своя специфика - Double обернут другим типом (так надо)
Значение этого типа может быть пустым - в ToString() должно вернуться String.Empty
Для этого в некоторых ситуациях создавал объект, пихая в поле Double Double.NaN
Что не понимаю - как это значение может вообще получиться использовать практически.
В прочем, по моей теме давно понятно, что от Double надо уходить
Reply
Например в JS\AS при выполнении операции var a = Number("shut up") на выходе получится isNaN(a) = true, т.к. конвертнуть строку в число не получилось. И все дальнейшие попытки использовать это значение в операциях будут приводить к NaN результату. Эксепшен в данном случае не генерится.
В языках, где числовые значения не являются чистыми объектами (т.е. то, что называется "примитивные типы"), для проверки на инициализацию значения используется сравнение c undefined - если переменной не было присвоено значение, то там вместо значения или NaN будет undefined (а не null, как иногда ошибочно полагают).
Reply
Reply
В C# мне известен только один способ присвоить NaN переменной
Double d = Double.NaN
или
Double d = Double(Double.NaN)
Конверсии производятся либо операторами приведения типов (либо success либо exception), либо (если из String) через Double.Parse(..) / Double.TryParse(..). При этом если значение будет записано - оно будет корректным.
Почему в этой ситуации не сделать так, чтобы Double.NaN был == Double.NaN мне не очень понятно. Хотя какой-то сакральный смысл наверное есть.
P.S. Double.IsNaN имеется кстати, да
Reply
И почти наверняка Double.Parse("green") даст NaN
Reply
в том-то и дело, что вылетит по исключению
Кстати, в Double представлены значения PositiveInfinity и NegativeInfinity
Т.е. это не NaN
Reply
Reply
Leave a comment