Как округление работает при умножении с плавающей запятой?

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

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

Точное (ближайшее представимое) число с плавающей запятой одинарной точности, соответствующее 0,7, равно 0b0.101100110011001100110011, что при обратном преобразовании в десятичное число равно 0,699999988079071044921875. Обратите внимание, что это число имеет 24 значащих бита, что является частью определения одинарной точности IEEE-754.

Умножив это число на 100, мы получим 0b1000101.1111111111111111111011. Но это число имеет 29 значащих битов, поэтому оно не умещается в 24 бита значения, доступных в одинарной точности. Поэтому нам придется округлить это. Теперь 25-й бит равен 1, поэтому мы округляем вверх, и почти все биты слева от этого 25-го бита равны 1, поэтому округление происходит до 0b1000110.00000000000000000, или ровно до 70,0.

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

И это хороший пример того, как работают правила IEEE-754 о правильном округлении результатов, и работают хорошо. Легко создать (ошибочное) впечатление, что значения с плавающей запятой всегда немного неправильны, если не совсем неправильны. Но на самом деле арифметика с плавающей запятой IEEE-754 обычно довольно точна и изо всех сил старается предотвратить накопление ошибок — а это означает, что нередко ошибки могут компенсировать друг друга, в конце концов давая точные результаты. Вот что в основном здесь происходит.

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

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

Если приведенное выше объяснение вам не подходит, вот другой способ взглянуть на него. Как мы знаем, представления с плавающей запятой не могут представлять все числа. Действительно, одно из чисел, которые они не могут представить в двоичном виде, — это 0,7, а ближайшее представимое число с одинарной точностью — это двоичное число, равное 0,699999988079071044921875.

А что, если мы возьмем это число 0,699999988079071044921875 и умножим его на 100? Точный результат должен быть 69,9999988079071044921875. Но это другое число, которое невозможно представить точно. Если вы возьмете непредставимое число 69,9999988079071044921875 и спросите, каким будет ближайшее число, которое можно представить точно с одинарной точностью, то это число будет... 70,0! В одинарной точности следующее представимое число, меньшее этого, равно 69,99999237060546875, что дальше (в данном случае более чем в 5 раз дальше), чем 70,0.

Вы также спросили о библиотеках с фиксированной запятой. Там ответ явно будет зависеть от реализации, но что еще важнее – от базы. Двоичная библиотека с фиксированной запятой также не может точно представлять 0,7. Но десятичная библиотека с фиксированной запятой, очевидно, могла бы.

Я думаю, что двоичное представление 0,7 с фиксированной запятой «8,8» будет 0000000010110011 (основание 2), или 00b3 (основание 16) или 179 (основание 10), что, преобразованное обратно в дробь, равно 0,69921875. Умножив это на 100, получим 100010111101100/45ec/17900, что снова преобразуется в 69,921875. Итак, исходя из этих предположений, я не вижу способа добиться большего (то есть способа получить 70,0).

Но если бы десятичная библиотека с фиксированной запятой дала вам 69 после умножения, я бы сказал, что она реализована довольно плохо. 16-битное десятичное представление с фиксированной запятой 0,7 с масштабным коэффициентом 100 будет равно 70, что при умножении на 100 дает 7000, что при повторном делении на масштабный коэффициент, очевидно, дает ровно 70,0.