Почему компьютеры используют двоичные числа в мантиссе IEEE754 вместо BCD или PDP?

Question

[Ланской Кирилл]

Почему компьютеры используют числа с плавающей точкой вместо BCD или DPD?

Это не дубликат этого вопроса, так как здесь я говорю только про плавающие числа Почему компьютеры не используют двоично-десятичный формат для вычислений?.
Приведу пример на 64 битном double в fraction 52 бита, если в этих 52 битах использовать BCD, мы получим очень точные числа без ошибок округления(13 значащих цифр, в обычном double 15-17, но будут накапливающиеся погрешности…). FPU считает IEEE 754, но тогда можно также создать и BCDU для вычислений таких BCD с sign и exponent. Но почему так не делают?

Я знаю, что в десятичной системе мы можем делить только на 2 и 5, но это будет более полезно для людей, потому что мы используем десятичную систему, и даже 1/3 будет точнее в десятичной системе, чем в двоичной, потому что в двоичной системе наименьшая разница между числами составляет 0,015625, в десятичной — 0,000001.

Модератору: Вы написали, что ответ легко ищется поиском в интернете, но нигде я не нашел ответа на мой вопрос.

Comments

[Everything_is_bad]

а при чем тут компьютерные сети?

[Ланской Кирилл]

Everything_is_bad, Ошибся, поправил

Answer 1

[Rsa97]

даже 1/3 будет точнее в десятичной системе, чем в двоичной

А давайте проверим.
В BCD упаковке мы получим 3.333333333333*10^-1, ошибка будет 3.(3)*10^-14
В двоичном представлении получим 1.0101010101010101010101010101010101010101010101010101*2^-1 = 3.33333333333333314829616256247*10^-1, ошибка 1.4829616256247*10^-17
То есть, ошибка в двоичном представлении в 2000 раз меньше, чем в BCD. А накапливаться ошибка будет и там и там.
Да, и 52 бита мантиссы на самом деле дают 53 бита значения, поскольку лидирующая единица всегда опускается.

Comments

[Ланской Кирилл]

Можете поподробнее объяснить как у Вас ошибка стала в 2000 раз меньше?

[Rsa97]

Ланской Кирилл,
(3*10^-14) / (1.5*10^-17) = (3*10³) / 1.5 = 2000

[Ланской Кирилл]

Rsa97, При этом эта разница превращается в всего лишь ещё три тройки, как раз примерно 2000(я не шучу), а за эти тройки в double получаем для 0.1: +0.1000000000000000055511151231257827021181583404541015625. Хотя мы чаще делим на десять, чем на три, так что важнее 3 цифры или точность десятичных чисел

[Rsa97]

Ланской Кирилл, Не "всего лишь ещё три тройки", а целых три десятичных разряда.
Для малых десятичных дробей точность важна, в основном, в финансах. Там давно уже придумали свой способ - вычисление проводят в десятых долях копеек, работая с целыми числами и финансовым округлением. Для вывода результат делят на 1000.
Ну и, опять же, вы всегда можете сконструировать свой IP-блок для операций с BCD и предложить его производителям процессоров.

[Ланской Кирилл]

Rsa97, Ещё есть PDP, который есть в IEEE754-2008, с ним что не так?

[Rsa97]

Ланской Кирилл, Неоднозначное представление чисел, увеличение сложности аппаратной реализации, ну и то же самое снижение точности.

Answer 2

[Saboteur]

Потому что BDC это не представление, а уже кодирование, упаковка.
Процессор не содержит инструкций по взаимодействию с таким представлением, поэтому вместо простой арифметической операции, тебе сперва придется декодировать числа, сохранить их где-то,затем снова закодировать.
Во-вторых тебе стоит попробовать построить обычный арифметический сумматор, чтобы понять как в принципе процессор считает числа. Вся арифметика основана на двоичной системе, а точнее на 0/1. И чтобы написать сумматор для BDC, потребуется куча лишних операций по декодированию таких чисел.
В результате в некотрых (не всех случаях), Ты сэкономишь чуть-чуть памяти, но количество операций для расчета увеличится в разы.

Comments

[Ланской Кирилл]

Сумматор я создавал, и не далеко не только его, Вы говорите про обычный int и проще и быстрее ничего нет, но плавающие числа не хранятся как int, это тоже кодировка: sign, exponent, fraction. Для операций над ними есть FPU(очень сложный ALU), а создать FPU или или условный BCDU разницы в плане скорости выполнения и сложности нет. Но BCD с мантиссой точнее. ALU IEEE754 не считает

[Saboteur]

Ланской Кирилл, Так создайте?

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

При этом затраты, повторюсь, миллиардные.
Опять же,