Безопасно ли проверять значения с плавающей запятой на равенство 0?

Я знаю, что обычно нельзя полагаться на равенство между значениями типа double или decimal, но мне интересно, является ли 0 особым случаем.

Хотя я могу понять неточности между 0,00000000000001 и 0,00000000000002, само значение 0 кажется довольно сложным, поскольку это просто ничего. Если вы неточны ни в чем, это уже не ничто.

Но я не очень разбираюсь в этой теме, поэтому не мне говорить.

double x = 0.0;
return (x == 0.0) ? true : false;

Всегда ли это будет верным?

Можно с уверенностью ожидать, что сравнение вернется trueтогда и только тогда, когда переменная double имеет значение точно 0.0(что, конечно же, имеет место в исходном фрагменте кода). Это соответствует семантике ==оператора. a == bозначает « aравно b».

Это не безопасно (потому что это не правильно ) ожидать , что результат некоторого расчета будет равен нуль в двойной (или в более общем плане , с плавающей точкой) арифметики , когда результат такого же расчет в чистой математике равен нуль. Это связано с тем, что, когда вычисления происходят на земле, появляется ошибка точности с плавающей запятой - концепция, которой нет в арифметике вещественных чисел в математике.

Если вам нужно провести много сравнений «на равенство», было бы неплохо написать небольшую вспомогательную функцию или метод расширения в .NET 3.5 для сравнения:

public static bool AlmostEquals(this double double1, double double2, double precision)
{
    return (Math.Abs(double1 - double2) <= precision);
}

Это можно было бы использовать следующим образом:

double d1 = 10.0 * .1;
bool equals = d1.AlmostEquals(0.0, 0.0000001);

Для вашего простого образца этот тест подходит. А как насчет этого:

bool b = ( 10.0 * .1 - 1.0 == 0.0 );

Помните, что .1 - это повторяющееся десятичное число в двоичном формате и не может быть представлено точно. Затем сравните это с этим кодом:

double d1 = 10.0 * .1; // make sure the compiler hasn't optimized the .1 issue away
bool b = ( d1 - 1.0 == 0.0 );

Я оставлю вас провести тест, чтобы увидеть фактические результаты: вы, скорее всего, так запомните.

Из записи MSDN для Double.Equals :

Точность сравнений

Метод Equals следует использовать с осторожностью, потому что два явно эквивалентных значения могут быть неравными из-за разной точности двух значений. В следующем примере сообщается, что значение Double 0,333 и значение Double, возвращаемое путем деления 1 на 3, не равны.

...

Вместо сравнения на равенство один из рекомендуемых методов включает определение допустимой разницы между двумя значениями (например, 0,01% от одного из значений). Если абсолютное значение разницы между двумя значениями меньше или равно этому запасу, разница, вероятно, связана с различиями в точности и, следовательно, значения, вероятно, будут равны. В следующем примере этот метод используется для сравнения .33333 и 1/3, двух значений Double, которые в предыдущем примере кода оказались неравными.

Также см. Double.Epsilon .

Проблема возникает, когда вы сравниваете различные типы реализации значений с плавающей запятой, например, сравнение float с double. Но с таким же типом проблем быть не должно.

float f = 0.1F;
bool b1 = (f == 0.1); //returns false
bool b2 = (f == 0.1F); //returns true

Проблема в том, что программист иногда забывает, что для сравнения происходит неявное приведение типа (двойное к float), что приводит к ошибке.

Если число было напрямую назначено для числа с плавающей запятой или двойной точности, то можно безопасно протестировать против нуля или любого целого числа, которое может быть представлено 53 битами для числа double или 24 битами для числа с плавающей запятой.

Или, говоря другими словами, вы всегда можете присвоить целочисленное значение двойному, а затем сравнить двойное с тем же целым числом и гарантировать, что оно будет равным.

Вы также можете начать с присвоения целого числа, и простые сравнения продолжат работать, придерживаясь сложения, вычитания или умножения на целые числа (при условии, что результат меньше 24 бит для числа с плавающей запятой и 53 бита для двойного). Таким образом, вы можете рассматривать числа с плавающей запятой и двойные числа как целые при определенных контролируемых условиях.

Нет, это не нормально. Так называемые денормализованные значения (субнормальные) при сравнении равных 0,0 будут сравниваться как ложные (ненулевые), но при использовании в уравнении будут нормализованы (станут 0,0). Таким образом, использовать это как механизм, позволяющий избежать деления на ноль, небезопасно. Вместо этого добавьте 1,0 и сравните с 1,0. Это гарантирует, что все субнормальные значения будут считаться нулевыми.

Попробуйте это, и вы обнаружите, что == ненадежно для double / float.
double d = 0.1 + 0.2; bool b = d == 0.3;

Вот ответ от Quora.

На самом деле, я думаю, что для сравнения двойного значения с 0,0 лучше использовать следующие коды:

double x = 0.0;
return (Math.Abs(x) < double.Epsilon) ? true : false;

То же самое для поплавка:

float x = 0.0f;
return (Math.Abs(x) < float.Epsilon) ? true : false;