равенство с плавающей точкой в Python и в целом

Позвольте мне сначала ответить, сказав, что вам следует прочитать классику Дэвида Голдберга Что должен знать каждый компьютерный ученый об арифметике с плавающей запятой .

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

Согласно модели с плавающей запятой, 2.54 на самом деле представляется как

>>> 2859785763380265 * 2 ** -50
2.54

Это представление, однако, не является точным:

>>> from fractions import Fraction
>>> float(Fraction(2859785763380265, 2 ** 50) - Fraction(254, 100))
3.552713678800501e-17

Теперь, выражение, которое вы оцениваете на самом деле:

>>> 25.4 / 10 * (1/2.54)
0.99999999999999989

Проблема заключается в 1 / 2.54:

>>> Fraction.from_float(1/2.54)
Fraction(1773070719437203, 4503599627370496)

Но что вы ожидаете, так это

>>> 1/Fraction.from_float(2.54)
Fraction(1125899906842624, 2859785763380265)

Чтобы ответить на ваши вопросы:

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

Как лучше всего избежать проблем вот так? ... На Python или вообще.

Какая проблема? Вы работаете с физическими измерениями. Если у вас нет действительно сложного оборудования, ошибка в ваших измерениях будет на несколько порядков выше, чем эпсилон с плавающей запятой. Так зачем писать код, который зависит от чисел, которые должны быть точными до 16 значащих цифр?

Должны ли компиляторы поддерживать возможность заменить все проверки равенства с плавающей запятой на функция «достаточно близко»?

Если бы это было так, вы бы получили странные результаты:

>>> float.tolerance = 1e-8    # hypothetical "close enough" definition
>>> a = 1.23456789
>>> b = 1.23456790
>>> c = 1.23456791
>>> a == b
True
>>> b == c
True
>>> a == c
False

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

Чтобы сравнить числа с плавающей запятой в целом, сравните абсолютное значение разности чисел с плавающей запятой с выбранной дельтой, которая достаточно мала, чтобы соответствовать вашим потребностям.

Риторические вопросы

• Это ** ЯВЛЯЕТСЯ опасной проблемой **, поскольку она может скрыть ошибки или создать бесконечные циклы, если такое сравнение используется в качестве критерия остановки.
• Современные компиляторы C / C ++ предупреждают о сравнении чисел с плавающей запятой на равенство
• Все известные мне средства проверки статического кода будут выводить ошибки для языков, которые я использую

Я полагаю, что для python это то же самое, что и дельта, используемая для сравнение может отличаться, выбор должен быть на усмотрение разработчика. Это означает, что невозможно обеспечить полностью автоматическое преобразование по умолчанию.

Разница в том, что если вы замените факторов [units_to] на 1.0 / 2.54 , вы сделаете:

(base_value * 1.0) / 2.54

Со словарем, вы делаете:

base_value * (1.0 / 2.54)

Порядок округления имеет значение. Это легче увидеть, если вы это сделаете:

>>> print (((25.4 / 10.0) * 1.0) / 2.54).__repr__()
1.0
>>> print ((25.4 / 10.0) * (1.0 / 2.54)).__repr__()
0.99999999999999989

Обратите внимание, что здесь нет недетерминированного или неопределенного поведения. Существует стандарт IEEE-754, которому реализации должны соответствовать (чтобы не утверждать, что они всегда соблюдают ).

Я не думаю, что должна быть автоматическая достаточно близкая замена. Часто это эффективный способ решения проблемы, но решать, использовать ли его и как это делать, должен сам программист.

Наконец, есть, конечно, варианты арифметики произвольной точности, включая python-gmp и decimal . Подумайте, действительно ли вам нужны они, потому что они действительно сильно влияют на производительность.

Нет проблем с перемещением между обычными регистрами и кешем. Возможно, вы думаете о 80-битной расширенной точности x86.

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

Это гораздо легче сказать, чем сделать. Природа плавающей точки делает фиксированную границу ошибки бесполезной. Небольшая граница ошибки (например, 2*float_epsilon) хорошо работает, когда значения близки к 0.0, но потерпит неудачу, если значения близки к 1000. Граница ошибки для значений размером 1 000 000.0 будет слишком слабой для значений, близких к 0.0.

Лучшее решение - знать область математики и выбирать подходящую границу погрешности в каждом конкретном случае.

Когда это непрактично или вы ленивы, Единицы в последнем месте (ULPs) - очень новое и надежное решение. Все детали довольно сложны, вы можете прочитать больше здесь.

Основная идея заключается в следующем: число с плавающей запятой состоит из двух частей, мантиссы и экспоненты. Обычно ошибки округления изменяют мантиссу лишь на несколько шагов. Когда значение близко к 0.0, эти шагов точно равны float_epsilon. Когда значение с плавающей точкой приближается к 1 000 000, шаги будут почти равны 1.

Тест Google использует ULP для сравнения чисел с плавающей точкой. Они выбрали значение по умолчанию 4 ULP для того, чтобы два числа с плавающей точкой сравнивались одинаково. Вы также можете использовать их код в качестве ссылки для создания собственного компаратора с плавающей точкой в стиле ULP.