Почему float точно, а Decimal неправильно?

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

Как вы указали, 3/9 повторяется 0,33, поэтому будет аппроксимироваться обеими схемами. В целом это будет верно, так как большинство чисел не могут быть представлены ни одной из систем, но о числах, которые заботят нас, людей, Decimal часто может быть легче рассуждать.

Несколько полезных инструментов, которые помогут понять, что здесь происходит, заключаются в том, что Decimal(float(value)) даст вам полное десятичное расширение value, а math.nextafter(value, math.inf) даст вам следующее представимое число с плавающей запятой после value.

Чтобы увидеть, что происходит внутри расчета, полезно увидеть промежуточные значения по мере их расчета. Я бы поступил следующим образом:

from decimal import Decimal as D

print(D(1) / 3, D(1 / 3), sep='\n')

Это должно распечатать:

0.3333333333333333333333333333
0.333333333333333314829616256247390992939472198486328125

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

Затем мы можем умножить на 27:

print(D(1) / 3 * 27, D(1 / 3) * 27, sep='\n')

Распечатка:

8.999999999999999999999999999
8.999999999999999500399638919

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

С помощью math.nextafter мы можем проверить, какие близлежащие значения находятся, чтобы понять, что операция округления выполняется правильно:

from math import nextafter, inf

print(D(nextafter(9, -inf)), D(1 / 3) * 27, D(nextafter(9, inf)), sep='\n')

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

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

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

Мы привыкли к неточным поплавкам по очевидным причинам.

Дело в том, что по большей части эти «очевидные причины» распространяются и на десятичные дроби.

Вы не можете представить дробь 1/3 в виде десятичной дроби. Вы можете приблизить его как 0,333 или 0,333333333, но независимо от того, сколько троек вы добавите в конце, оно никогда не будет точным. И если вы снова умножите это на 3, вы получите 0,999999999, а не 1,0.

Вы не можете точно представить π = 3,141592654 ни в десятичном, ни в двоичном виде.
Вы не можете точно представить √2 = 1,41421356 ни в десятичной, ни в двоичной форме.
Вы не можете точно представить e = 2,718281828… ни в десятичном, ни в двоичном виде.

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

Один из аспектов того, что десятичная дробь «лучше» двоичной, заключается в том, что с математической точки зрения не существует двоичных дробей, которые нельзя было бы точно преобразовать в десятичные, в то время как существует множество десятичных дробей (фактически большинство из них), которые не могут быть преобразованы в десятичные дроби. быть преобразованы точно в двоичный файл. То есть, если у вас есть двоичная дробь типа 0b1.010101, вы всегда можете преобразовать ее в точную десятичную дробь 1,328125, но если у вас есть даже самая простая десятичная дробь 0,1, при попытке преобразовать ее в двоичную вы получите бесконечно повторяющийся узор 0b0.0001100110011….

Но это все вроде фона и не отвечает на ваш другой вопрос. Почему 27*(3/9) дает вам точный ответ в двоичном виде, а не в десятичном, хотя 3/9 не может быть точно представлен ни в десятичном, ни в двоичном виде? И ответ заключается в том, что ошибка округления является своего рода случайной, и иногда две ошибки округления компенсируют друг друга. В IEEE-754 с плавающей запятой, которую, вероятно, использует Python, ближайшее значение двойной точности к 3/9 — это 53-битная двоичная дробь, которая точно равна 0,3333333333333333314829616256247390992939472198486328125 . Если умножить это число на 27, то точный ответ будет 8,9999999999999999500399638918679556809365749359130859375. IEEE-754 говорит, что при умножении полученный результат (если он неточный) должен быть правильно округленной версией точного результата, и это число достаточно близко к 9,0, чтобы оно действительно округлялось.

Я не уверен, как реализован тип Python Decimal. Либо у него нет такой же гарантии округления фактического результата, либо в конечном итоге получается, что точный результат (в десятичном виде) ближе к 8,999999999999999999999999999, чем к 9,0.

Сноска: я сказал, что «ошибка округления случайна», но на самом деле это не так. Теоретик чисел мог бы точно сказать нам, какие результаты будут точными, а какие приблизительными, мог бы точно сказать нам, когда две ошибки округления компенсируют друг друга, а когда они сохранятся. Но я недостаточно знаю теорию чисел, чтобы даже попытаться привести такой аргумент.