Ошибся не я, а природа, которая все это устроила. Еще раз повторюсь, речь идет не о точности конвертации чисел из одной системы счисления в другую, а о результатах вычислений.
К сожалению, если бы мы в жизни использовали шестнадцатиричную, восьмеричную или, на худой конец, двоичную систему счисления, проблем бы с компьютерными вычислениями не было. Но мы, как правило, оперируем с десятичными числами и пытаемся заставить компьютер их понимать. И получать информацию от него мы хотим в десятичном виде, как привыкли.
В самом большом числе из приведенных всего 3 знака после запятой (1234.567). А вот после конвертации оно становится
1234.56710 = 1.0011010010.100100010010011011101001〖∙2〗^10
=1234.5670166015625
Так про какой 5 знак идет речь?
Алгоритм Кэхэна работает за счет привлечения еще одного операционного программного регистра в дополнение к аппаратному. Это все равно, что увеличить в два раза аппаратный регистр. При этом проблема неверных цифр («хвоста») не пропадает.
Если говорить о погрешности представления — разная для разных чисел
2) Вы снова передергиваете и приводите числа, не представимые в конечном двоичном коде.
Я все время именно о таких числах и веду речь. Представимые числа — точные и с ними проблем нет до тех пор пока в результате арифметических действий они не превращаются в приблизительные.
Так и я о том же. Как только вы преобразовали десятичное число к двоичному, вы ошиблись не в 5 знаке, а в 10000… знаке. Так как получили бесконечную дробь.
В соответствие с правилами арифметических операций, чтобы сложить/умножить/разделить два числа с точностью до N-го знака после запятой, каждое число должно быть округлено до N знаков. Делая арифметические операции над двоичными числами, которые приблизительно представляют исходные десятичные, мы не можем выполнить этого требования, т.к. уменьшение разрядности двоичного числа делает его менее точным в его десятичном представлении. Таким образом, мы имеем нарушения правил сложения десятичных приблизительных чисел, в результате которого мы получаем неверный результат.
Все, что касается десятичной арифметики, Вы все правильно написали. Но, в моей статье идет речь о попытках решения арифметических десятичных задач с использованием двоичной арифметики. Когда мы считаем на калькуляторе, он не знает природу происхождения цифр, точные они или приблизительные. Он честно выдает тот результат, который должен быть получен по правилам арифметических действий в пределах своей разрядной сетки. Для калькулятора это точные числа. Только мы знаем природу этих чисел и дальше поступаем с ними так, как считаем нужным, например так, как в вашем примере. Но, когда мы два точных дробных числа преобразуем в двоичные ЧПТ, чтобы быстро посчитать, мы из точных десятичных получаем приблизительные десятичные, которые содержат верные и неверные цифры. Влияние этих неверных цифр приводит к серьезным погрешностям. Чем длиннее двоичная мантисса ЧПТ, тем дальше отодвигаются неверные числа и меньше влияют на получение верных цифр при арифметических действиях. Но в любом случае хвост оказывает влияние на результат и существенно сужает диапазон точности. И есть такие случаи, когда это влияние становится столь велико, что наш инструмент становится непригоден для использования. Беда в том, что эти случаи очень трудно обнаружить.
Уважаемый! Нельзя ночью писать коменты, Судя по всему, при изложении своих мыслей, вы пользуетесь принципом «пишите как удобно, компилятор сам преобразует».
Если по существу,
Почему вы утверждаете что при точности в 5 знаков результат сложения тоже 5 знаков?
Если следовать вашим знаниям, то в формате float, после 7 шагов суммирования, мы уже имеем совершенно неверный результат, даже, если складывались точные числа. Ну или 16 шагов для дабл.
Правильно. Если вычислять по правилам арифметики с точностью до 15 знака, с калькулятором мы делаем все верно. Если вычислять до 15 знака после запятой в формате дабл, и значащие цифры считать от точки в ненормализованном числе, то хвост не мешает. Арифметические операции не приближают неверные цифры к точке. Но, если считать по количеству значащих десятичных цифр, или от точки, в нормализованном числе, то хвост попадает в область верных цифр или участвует в образовании младшей значащей десятичной цифры. Проблема в том, что отсечение хвоста в двоичном коде увеличивает хвост в десятичном представлении и приближает неверные десятичные цифры к точке. Чтобы все было корректно, надо на каждом операционном шаге десятичное представления результата округлять до нужного значения
1234.56710 = 1.0011010010.100100010010011011101001〖∙2〗^10
=1234.5670166015625
Так про какой 5 знак идет речь?
Если говорить о погрешности представления — разная для разных чисел
Я все время именно о таких числах и веду речь. Представимые числа — точные и с ними проблем нет до тех пор пока в результате арифметических действий они не превращаются в приблизительные.
У меня получилось 0.0069580
Если по существу,
Если следовать вашим знаниям, то в формате float, после 7 шагов суммирования, мы уже имеем совершенно неверный результат, даже, если складывались точные числа. Ну или 16 шагов для дабл.