За окном начало 90-х. Происходит массовый переход на персональные компьютеры. Для большинства это означает смену всего, включая язык программирования. Для большинства, но все же не для всех. Один мой хороший знакомый вовсе не собирается переписывать свои тексты при уходе с ЕС ЭВМ. Задачи у него вычислительные, довольно объемные. И все его силы уходят на разработку модели, прогоны и анализ результатов. Программирование считает делом второстепенным, просто как правила записи текстов и при этом очень консервативен: написанное однажды старается больше не менять, поскольку, мол, это уже отлажено. Всегда занят кучей дел, поэтому просит меня помочь ему с переносом программ на x86. Для начала добиться, чтобы результаты на EC-1045 и IBM-PC/AT совпадали цифра в цифру.
Хорошо, соглашаюсь я и получаю для сверки кучу распечаток с ЕС. Строгого совпадения сходу не видно и я начинаю последовательно сравнивать промежуточные результаты.
Странное дело! Расхождение начинается в совершенно безобидном месте, там, где вещественное число 4 байта преобразуется в вещественное же, но в 8 байт. Конкретно значение 1.2512Е+00 превращается почему-то 1.25119996070860E+000. А на ЕС это же значение преобразуется в интуитивно ожидаемые 1.25120000000000E+00. Что за черт? Преобразование на персоналке идет через FPU, точнее, тогда в 90-х, еще через отдельный «математический сопроцессор». В него загружается 4-байтное число, а затем оно же «выгружается» обратно в память, но уже как 8-байтное. Так-так. Понятно. В FPU двоичная мантисса просто расширяется нулями. И в таком виде выдается обратно. Но такое «круглое» двоичное число выглядит совсем некруглым в десятичном виде. Интересно, значит, в IBM-360 в свое время все-таки озаботились подгонкой мантиссы под «круглые» десятичные значения?
Объясняю это «заказчику», но он недоволен и не понимает.
— Не должно быть никаких ненулевых цифр в мантиссах. Это же просто другое значение.
— Да нет, погрешность все равно не превышает половины младшего разряда. И вообще выкинул бы ты все вещественные переменные 4 байта. На кой ляд они тебе. И «ошибки» преобразования исчезнут…
— Твое дело – добиться совпадения, а не указывать, как программы менять. Работали они – не тронь!
Ладно, думаю. Поправлю-ка я системную библиотеку в части преобразования. Только вот как нули-то получить, раз сопроцессор отказывается их подбирать? Надо что-нибудь попроще. Например, вот так: перевести число в текст, дописать текстовую строку кучей нулей справа и преобразовать обратно в IEEE-754. Медленно, зато будет точно как у IBM-360. Получилось. Все результаты совпали, «заказчик» остался доволен.
Однако через пару месяцев опять он связь выходит. Слушай, говорит, чего-то программа стала работать заметно медленней. Посмотри. А чего смотреть-то? Ну, вычисления и вычисления. А то, что я преобразования новые добавил, так они всего в паре мест и вне циклов, т.е. по времени неощутимо. Ладно, посмотрю. Глянул – а там чуть не через каждые десять команд те самые преобразования через текст и дописывание нулей. Оказалось, один символ в тексте программы случайно потерли. (Небось, ногтем за «Backspace» зацепили.) И в одном месте в описании вместо DECIMAL FLOAT(16) получился текст DECIMAL FLOAT(6).
Т.е. как раз вместо IEEE-754 8 байт случайно получилось IEEE-754 4 байта. И, конечно же, по закону пакости эта переменная во всех формулах оказалась задействована и везде включился свежеиспеченный алгоритм формирования круглых чисел. Поправили, преобразования исчезли, скорость восстановилась и ЕС-1045 окончательно потеряла одного из своих последних пользователей.
Вопрос, правда, остался. При расширении мантиссы числа с «плавающей» точкой, надо ли делать «круглое» десятичное число? Или достаточно «круглого» двоичного. И почему 50 лет назад в IBM-360 все-таки сделали «круглое» десятичное? С точки зрения погрешности вычислений «круглые» числа ведь ничего не дают. Или все-таки дают?
Здравствуйте, кт, Вы писали:
кт>Здравствуйте, netch80, Вы писали: N>>А что калькуляторы? кт>Да так, ничего, просто пример типичного отношения
кт> От: netch80 Дата: 08.04.16 15:59
кт>"Не смешите. Двоично-десятичная в 8080 (!) введена для работы с устройствами, которые вводят и выводят короткие числа в десятичном виде, как часы. Это был процессор для микроконтроллеров, и предложение использовать его для финансов встретило бы только дикое недоумение всех понимающих. кт>На этой "арифметике" вы нормально сделаете только сложение и вычитание — любых размеров, умножение и деление — только на одну цифру. Всё более сложное на ней выливается в дикий гемор, что проще делать через двоичку. Хорошо же средство для "финансов", что не может нормально вычислить несчастные 18% VAT или 3.3% сложного процента по кредиту.
Ну, что я это писал, помню, и позицию тут не меняю. Но от BCD для микроконтроллеров до того, что сейчас считают калькуляторами, таки заметная дистанция. И на современных средствах лучше даже десятичные калькуляторы делать никак не на BCD, а набирая в uint32 по 9 десятичных цифр, или как-то аналогично.
кт>В 8086 во всей линии вплоть до последних 32-разрядных версий это просто наследие, которое в линии IBM PC перестало быть ценным. В x86-64 его исключили как то, что уже лет 15 перед этим перестало быть хоть кому-то ценным".
кт>От себя замечу, чтобы выводить короткие числа как часы никаких специальных команд не требуется кт>MOV AL,hour кт>MOV AH,10 кт>DIV AH кт>ADD AL,'00'
кт>и получаются часы в виде текста
Не так. Во-первых, в часах обычно никто не делит, только складывают, вычитают, инкрементируют, декрементируют, сравнивают. Соответственно, основные команды — DAA, DAS.
Во-вторых, деление убойно дорогое. На 8086 такое деление от 80 тактов (80, Карл!) При малейшей критичности этого участка он был бы заменён на что-то вроде
что было бы дешевле во всех случаях.
(А на современном процессоре вообще тут же заменена обратным умножением.)
А группа команд AAx вообще, по-моему, имеет смысл чуть менее, чем никакой. В той цитате я думал про DAx, а не AAx. Может, недостаточно чётко выразился.
Здравствуйте, кт, Вы писали:
кт>уж слишком много вопросов и все они опять на тему BCD
Подветка же про BCD
кт>При точных финансово-экономических расчетах после транзакций не должны появляться деньги из воздуха или пропадать из-за округлений.
Совершенно верно. Для этого достаточно считать, что все суммы представлены с точностью до копеек. Все — итоги любого расчета, суммы всех документах, на расчетных и бухалтерских счетах. И следить за тем, что бы одна и та же сумма в разных местах, например в в документах предоставляемых клиенту/контрагенту и во внутренней бухлалтерии были равна. Это обеспечивается не способом машинного представления чисел.
кт>Вот пример неправильного округления. Лимит возник из воздуха. кт>http://files.rsdn.org/122727/limit.jpg
Может из воздуха, а может нет. Там одна копейка, сумма вполне допустимая.
Возможно так было задумано. Или в ТЗ забыли написать, что если лимит в результате расчетов получается меньше n копеек его нужно принимать равным 0 копеек. Сложно сказать не зная откуда берется этот лимит.
кт>разница между decimal fixed и int32 в том, что, например, при умножении двух DECIMA(x,2) получится число типа DECIMAL(X+X,2+2+1) и транслятор это автоматически учитывает
А что транслятор делает при делении? вешается?
кт>а для int32 это все надо будет определять самому. Обратите внимание, что числа хранятся с двумя знаками (пусть копейками), а точность вычислений получается 4 знака (5 для комплексных) после точки.
А если хранить в целых копейках, то результат окажется тоже в копейках, и транслятору страдать не придется. Правда в квадратных копейках, но умножать деньги на деньги не я предложил. Хранить коплексные числа в BCD идея ничем не лучше, чем хранить таким способом целые.
кт>И можно правильно и "точно" округлять простым присваиванием в переменную соответствующего типа, например опять в FIXED(x,2)
И каким же округлением — с отбрасыванием дробной части, бухгалтерским или банковским?
кт>А если представлять сотые копейки как целые, то и точность будет только до сотых и округдения могут быть неправильные (как на фото)
Только при делении, а правильное округление при деление и для int и для DECIMAL(x,2) нетривиально. Оно просто только для float/double, но они Вам не нравятся еще больше.
С какой точностью в ПЛ/1 результат деления после вычисления выражения в последнем операторе, но до приваивания Z ?
DECLARE X DECIMAL(x,2),
Z DECIMAL(x,2);
X = Y;
Z = X/I;
кт>Например, сложение чисел из ESI и EDI, просто, быстро, универсально, не завязано на размер слова
кт> CLC кт>M: LODSB кт> ADC AL,[EDI] кт> DAA кт> STOSB кт> LOOP M
Так то сложение, а если захочется умножить, да еще способом побыстрей, а не простейшей заменой умножения сложением в цикле. А если делить?
кт>Кстати, числа очень большой длины используются при поиске больших простых чисел.
Используются. кт>А большие простые числа, например, сейчас используются в криптографии.
При этом быстродействие очень важно. И для BCD оно всегда будет намного меньше, даже при полноценной аппаратной реализации, если кто-то вдруг таки сделает её. Только двоичные целые.
Здравствуйте, кт, Вы писали:
кт>Вопрос, правда, остался. При расширении мантиссы числа с «плавающей» точкой, надо ли делать «круглое» десятичное число? Или достаточно «круглого» двоичного. И почему 50 лет назад в IBM-360 все-таки сделали «круглое» десятичное? С точки зрения погрешности вычислений «круглые» числа ведь ничего не дают. Или все-таки дают?
Тестеры бывают докапаваются — вводят "круглые" десятичные числа, а потом видите ли значения их пугают
Здравствуйте, кт, Вы писали:
кт>Вопрос, правда, остался. При расширении мантиссы числа с «плавающей» точкой, надо ли делать «круглое» десятичное число?
Не надо. Но точность в младших разрядах мантиссы интересует не нужно преобразовывать туда-сюда без надобности.
кт> Или достаточно «круглого» двоичного.
Пока 4-байтовым было хватало, значит достаточно. Если не достаточно, то нужно изначально использовать 8-байтовое.
кт> И почему 50 лет назад в IBM-360 все-таки сделали «круглое» десятичное?
Это очень странно. Жаль сейчас не проверить. Но предполагаю, что это не архитектурная IBM-360, а особенность преобразования типов в том применяемом языке. PL/1 ?
кт> С точки зрения погрешности вычислений «круглые» числа ведь ничего не дают. Или все-таки дают?
Этим вопросом нужно задаваться когда принимается решение о разрядности используемых переменных и вычислений пользоваться.
Здравствуйте, кт, Вы писали:
кт>И в одном месте в описании вместо DECIMAL FLOAT(16) получился текст DECIMAL FLOAT(6).
А вот у меня при переносе программ с ЕС на PC никаких вычмслительных проблем не возникло. А все потому, что те, кто начинал проект, в качестве основного языка выбрали Фортран. И не ленились писать IMPLICIT DOUBLE PRESIGION везде, где нужно. Причем все нармально работало и в MS DOS, и с DOS-extender-ом, и в Чикаге, и в Полуоси.
кт>Вопрос, правда, остался. При расширении мантиссы числа с «плавающей» точкой, надо ли делать «круглое» десятичное число? Или достаточно «круглого» двоичного. И почему 50 лет назад в IBM-360 все-таки сделали «круглое» десятичное? С точки зрения погрешности вычислений «круглые» числа ведь ничего не дают. Или все-таки дают?
Здравствуйте, Privalov, Вы писали:
P>Это о чем? О поддержке DECIMAL FIXED?
Нет, вопрос о том, что должно выдавать FPU после команд
FLD32 X1
FST64 X2
Если X1=1.2512
Почему-то ждут, что 1.25119999999999
А FPU выдает другой результат
Здравствуйте, pagid, Вы писали:
кт>>Вопрос, правда, остался. При расширении мантиссы числа с «плавающей» точкой, надо ли делать «круглое» десятичное число? P>Не надо.
Я не столь уверен. Получается, у программиста нет способа указать, что мантисса "точная" и он получает представление числа не с минимально возможной погрешностью. P>Но точность в младших разрядах мантиссы интересует не нужно преобразовывать туда-сюда без надобности.
Это точно. Особенно, когда весь расчет случайно, правда, превратился в одно сплошное преобразование.
кт>> Или достаточно «круглого» двоичного. P>Пока 4-байтовым было хватало, значит достаточно. Если не достаточно, то нужно изначально использовать 8-байтовое.
Тут речь не совсем об этом. Никто не задумывался, что мантиссу с десятичными нулями FPU просто так, по умолчанию, искать не будет.
кт>> И почему 50 лет назад в IBM-360 все-таки сделали «круглое» десятичное? P>Это очень странно. Жаль сейчас не проверить. Но предполагаю, что это не архитектурная IBM-360, а особенность преобразования типов в том применяемом языке. PL/1 ?
Возможно не архитектура, но все равно только так. Кстати, у PL/1 и Фортрана расчетная, числовая часть полностью совпадает, точнее все из Фортрана просто перенесено в PL один к одному.
кт>> С точки зрения погрешности вычислений «круглые» числа ведь ничего не дают. Или все-таки дают? P>Этим вопросом нужно задаваться когда принимается решение о разрядности используемых переменных и вычислений пользоваться.
Ну, хозяин-барин отказался исключать старые типы: дескать, как на ЕС работало — так и надо.
Здравствуйте, кт, Вы писали:
кт>Я не столь уверен. Получается, у программиста нет способа указать, что мантисса "точная" и он получает представление числа не с минимально возможной погрешностью.
На реальной архитектуре точность же не произвольная, максимум два варианта. Float и double в современных языках это полностью покрывают. А возможность указать "произвольную" точность это еще один косяк PL/1, и в вашем случае он проявился.
Только что заметил. Там на самом деле было DECIMAL FLOAT(16), а не BINARY FLOAT(16)
Тогда все понятно. И почему представление и преобразование было "точным" и почему у вас задачи считались целыми ночь вместо максимальных двух часов.
кт>Ну, хозяин-барин отказался исключать старые типы: дескать, как на ЕС работало — так и надо.
Так изначально не нужно было DECIMAL использовать. А так да, эмулировать его чисто программно на Intel, но и на ЕС он должен был быть в значительной степени программым.
Здравствуйте, кт, Вы писали:
кт>Странное дело! Расхождение начинается в совершенно безобидном месте, там, где вещественное число 4 байта преобразуется в вещественное же, но в 8 байт. Конкретно значение 1.2512Е+00 превращается почему-то 1.25119996070860E+000. А на ЕС это же значение преобразуется в интуитивно ожидаемые 1.25120000000000E+00.
На StackOverflow вопрос "а почему плавучка сломана" с приведением примера типа 0.3 != 0.1 * 3 задаётся в среднем раз в 2 дня. Наверно, это рекордсмен среди тупых вопросов.
И именно для максимальной понятности работы с плавучкой на современных потомках ЕС ЭВМ (в лице zSeries) сделали _аппаратную_ поддержки десятичной плавучки (эта реализация принята в IEEE 754-2008).
кт>Однако через пару месяцев опять он связь выходит. Слушай, говорит, чего-то программа стала работать заметно медленней. Посмотри. А чего смотреть-то? Ну, вычисления и вычисления. А то, что я преобразования новые добавил, так они всего в паре мест и вне циклов, т.е. по времени неощутимо. Ладно, посмотрю. Глянул – а там чуть не через каждые десять команд те самые преобразования через текст и дописывание нулей. Оказалось, один символ в тексте программы случайно потерли. (Небось, ногтем за «Backspace» зацепили.) И в одном месте в описании вместо DECIMAL FLOAT(16) получился текст DECIMAL FLOAT(6).
А как именно работал там DECIMAL FLOAT?
На старой — через BCD арифметику S/360? А то "честным" float там такого нельзя было сделать (там была двоичная плавучка с другими особенностями, но сильно похожая на современную).
На новой — явно же тоже не через обычный float?
кт>Т.е. как раз вместо IEEE-754 8 байт случайно получилось IEEE-754 4 байта.
Точно IEEE754? А то ой сомнительно, судя по описанному.
кт>Вопрос, правда, остался. При расширении мантиссы числа с «плавающей» точкой, надо ли делать «круглое» десятичное число? Или достаточно «круглого» двоичного. И почему 50 лет назад в IBM-360 все-таки сделали «круглое» десятичное? С точки зрения погрешности вычислений «круглые» числа ведь ничего не дают. Или все-таки дают?
В родной плавучке S/360 (той, которая в ассемблерных командах с суффиксом D) не было десятичного режима.
А как работал текстовый импорт — надо уточнять, у меня под рукой нет деталей.
Здравствуйте, pagid, Вы писали:
P>Только что заметил. Там на самом деле было DECIMAL FLOAT(16), а не BINARY FLOAT(16)
BINARY FLOAT(16) — это как-то мало. ЕМНИП, 53 должно быть.
P>Тогда все понятно. И почему представление и преобразование было "точным" и почему у вас задачи считались целыми ночь вместо максимальных двух часов.
В PL/1, ЕМНИП, по умолчанию использовался тип DECIMAL FLOAT. Кроме переменных, имена которых начинались с определенных букв (K, L, M, N, I, J, по-моему). Такие переменные были BINARY FIXED.
Некоторые вообще DECIMAL FIXED в расчетах использовали. И ничего, как-то прокатывало.
Здравствуйте, Privalov, Вы писали:
P>А вот у меня при переносе программ с ЕС на PC никаких вычмслительных проблем не возникло. А все потому, что те, кто начинал проект, в качестве основного языка выбрали Фортран. И не ленились писать IMPLICIT DOUBLE PRESIGION везде, где нужно.
Ну так переход с S/360 double на IEEE754 double был прогрессивен во всём. Больший диапазон порядков (10^308 против 10^76), более аккуратное округление (ширина 56 бит при базе порядка 16 в S/360 давала результаты не лучше, чем ширина 53 бита при базе 2; к тому же арифметика S/360 имела только 1 round bit против 3 — round+guard+sticky в IEEE754, а по умолчанию в FPU вообще extended на 64 бита сохранённой мантиссы).
Вот с single были некоторые проблемы за счёт сокращения диапазона порядков до 10^38, но и то вылазили у редчайших клиентов, а остальные были довольны устойчивыми 24 битами мантиссы, вместо 21-24, как в S/360.
P> Причем все нармально работало и в MS DOS, и с DOS-extender-ом, и в Чикаге, и в Полуоси.
А при чём тут ось? Важнее само наличие FPU, и какие библиотеки используются, если его нет. К MS Фортрану шли режимы fp{i,c}[87], которые гарантированно точные, и fpa, которая быстрая и неточная. Вот с fpa библиотекой можно было иногда получать странноватые результаты — но на наших тогдашних XT и AT/286 без FPU это было всё равно хорошо.
Здравствуйте, pagid, Вы писали:
P>>BINARY FLOAT(16) — это как-то мало. ЕМНИП, 53 должно быть.
P>Тогда мне изменила помять, в том что значит BINARY/DECIMAL в этом описании. Посыпаю голову пеплом.
Честно говоря, я совсем не помню разницу между BINARY и DECIMAL FLOAT. С FIXED все ясно. Если BINARY, то речь идет о двоичном числе. А если DECIMAL, то число хранится в двоично-десятичном упакованном формате, и вычисления на таких числах страшно тормозят. А вот с FLOAT надо литературу поднимать. Но что-то мне подсказывает, что DEC FLOAT (16) и BIN FLOAT(53) — это одно и то же. Но боюсь наврать.
Здравствуйте, Privalov, Вы писали:
P>Честно говоря, я совсем не помню разницу между BINARY и DECIMAL FLOAT. С FIXED все ясно. Если BINARY, то речь идет о двоичном числе. А если DECIMAL, то число хранится в двоично-десятичном упакованном формате, и вычисления на таких числах страшно тормозят.
Вот это меня и спутало. На первый взгляд и логично ожидать, что и с FLOAT так же.
P> А вот с FLOAT надо литературу поднимать. Но что-то мне подсказывает, что DEC FLOAT (16) и BIN FLOAT(53) — это одно и то же. Но боюсь наврать.
Похоже на то.
Но тогда остается вопрос, как это числа так ловко "округлялись" при преобразовании в двойную точность. Какие-то процедуры стандартной библиотеки языка неявно вызывались? но что-то сомнения меня гложут, и всяко-разно тогда в Фортрановском компиляторе должно было быть сделано так же, что еще большие сомнения вызывает.
Здравствуйте, netch80, Вы писали:
N>Вот с single были некоторые проблемы за счёт сокращения диапазона порядков до 10^38, но и то вылазили у редчайших клиентов, а остальные были довольны устойчивыми 24 битами мантиссы, вместо 21-24, как в S/360.
Я в курсе. У нас REAL*4 просто нигде не использовалось. Переход прошел практически безболезненно.
P>> Причем все нармально работало и в MS DOS, и с DOS-extender-ом, и в Чикаге, и в Полуоси.
N>А при чём тут ось?
Да в общем, конечно, ни причем. Я просто вспомнил, как в MS DOS нарвался на сегментную память. Пришлось длинным массивам атрибут HUGE навесить. Вычисления, разумеется, шли везде одинаково. FPU присутствовал у нас везде.
N>Вот с fpa библиотекой можно было иногда получать странноватые результаты — но на наших тогдашних XT и AT/286 без FPU это было всё равно хорошо.
FPU, как я уже сказал, у нас были всегда, поэтому эта штука оказалась не нужна. Даже на 286.
Здравствуйте, Privalov, Вы писали:
P>Честно говоря, я совсем не помню разницу между BINARY и DECIMAL FLOAT. С FIXED все ясно. Если BINARY, то речь идет о двоичном числе. А если DECIMAL, то число хранится в двоично-десятичном упакованном формате, и вычисления на таких числах страшно тормозят.
Кстати о тормозах, но ведь у x86-х же есть в железе BCD-формат, но на практике его кажется очень мало кто из компиляторов использовал.
Здравствуйте, Michael7, Вы писали:
M>Кстати о тормозах, но ведь у x86-х же есть в железе BCD-формат, но на практике его кажется очень мало кто из компиляторов использовал.
Это наследие i8080, а возможно даже и i8008 предназначенного для калькуляторов. В x64 BCD нет
Здравствуйте, pagid, Вы писали:
P>Это наследие i8080, а возможно даже и i8008 предназначенного для калькуляторов. В x64 BCD нет
Я о том, что в описываемой ситуации (когда никакого x64 не было, но был BCD) при миграции с ЕС на ПК этим можно было бы, наверное, воспользоваться. Хотя хз, это не плавучка по-любому была, но все-равно вероятно могло помочь при программной реализации типа.
Здравствуйте, Michael7, Вы писали:
M>Я о том, что в описываемой ситуации (когда никакого x64 не было, но был BCD) при миграции с ЕС на ПК этим можно было бы, наверное, воспользоваться. Хотя хз, это не плавучка по-любому была, но все-равно вероятно могло помочь при программной реализации типа.
Это работало бы очень медленно. Там очень примитивные BCD команды.
N>А как именно работал там DECIMAL FLOAT? N>На старой — через BCD арифметику S/360? А то "честным" float там такого нельзя было сделать (там была двоичная плавучка с другими особенностями, но сильно похожая на современную).
Через BCD работал DECIMAL FIXED. Это я на всю жизнь запомнил. А DECIMAL FLOAT работал, ЕМНИП, как фортрановское REAL. Но все же боюсь наврать.
Здравствуйте, pagid, Вы писали:
M>>Кстати о тормозах, но ведь у x86-х же есть в железе BCD-формат, но на практике его кажется очень мало кто из компиляторов использовал. P>Это наследие i8080, а возможно даже и i8008 предназначенного для калькуляторов. В x64 BCD нет
Интересно, в какой книге первой было написано, что BCD нужно для калькуляторов и его забыли выкинуть из 8080 после 8008?
BCD нужно для финансово-экономических расчетов и его использовали все компиляторы с Кобола, например.
Финансово-экономические расчеты никуда не делись, а вот новое поколение разработчиков Intel о них, похоже, ничего не знает
Здесь это уже обсуждалось не раз, но опять в памяти остаются только калькуляторы.
Здравствуйте, кт, Вы писали:
M>>>Кстати о тормозах, но ведь у x86-х же есть в железе BCD-формат, но на практике его кажется очень мало кто из компиляторов использовал. P>>Это наследие i8080, а возможно даже и i8008 предназначенного для калькуляторов. В x64 BCD нет кт>Интересно, в какой книге первой было написано, что BCD нужно для калькуляторов и его забыли выкинуть из 8080 после 8008?
Ну раз его выкинули в amd64, наверно, он таки нинужен™? Особенно в таком варианте по одной цифре.
В zSeries, наоборот, ввели полноценную десятичную плавучку, но там не одна цифра (7 и 16 в decimal 32 и 64 соответственно), и в gcc есть поддержка для неё.
кт>BCD нужно для финансово-экономических расчетов и его использовали все компиляторы с Кобола, например.
Что нужен — я согласен на 99.9%, что использовали — да, а вот что делали это корректно и полезно — сомневаюсь. Можно ли было, например, обнаружить в них, что 9999999.00+0.0001 давало снова 9999999.00? Или на такие случаи всё надо было проверять обратным вычитанием и прочими defensive мерами?
кт>Финансово-экономические расчеты никуда не делись, а вот новое поколение разработчиков Intel о них, похоже, ничего не знает
Знает, насколько я видел, и читает советы типа "такое считать только в fixed целыми в 1/10000 цента". И это таки обычно быстрее и надёжнее, чем все эти decimal float.
кт>Здесь это уже обсуждалось не раз, но опять в памяти остаются только калькуляторы.
Здравствуйте, кт, Вы писали:
кт>Интересно, в какой книге первой было написано, что BCD нужно для калькуляторов и его забыли выкинуть из 8080 после 8008?
Так критерий истинности не книжки, где можно найти любые угодные ответы на любые вопросы, а практика. И BCD возможности не использовали ни компиляторостроители, ни писатели программ на ассемблере. Нужно ли его было выкидывать из 8080 , но в х86 его уже никто не использовал. Возможно потому, что BCD-арифметика совсем никому не нужна, возможно потому что её реализация в x86 это всего лишь повторение примитивнейших команд из калькуляторного i8008.
кт>BCD нужно для финансово-экономических расчетов и его использовали все компиляторы с Кобола, например.
Только кто же этот Кобол видел Он остался только в глубоком легаси и только на Западе. Неужели ранее в СССР и сейчас не занимаются финансово-экономическими расчетами? И при этом успешно обходятся без Кобола и BCD встроенного в архитектуру процессоров.
кт>Финансово-экономические расчеты никуда не делись, а вот новое поколение разработчиков Intel о них, похоже, ничего не знает
Новое поколение разработчиков Intel и старое поколение разработчиков AMD все прекрасно знает. И оценивает необходимость BCD в системе команд здраво.
кт>Здесь это уже обсуждалось не раз, но опять в памяти остаются только калькуляторы.
Совершенно верно, обсуждалось. И Вы тогда так и не объяснили чем BCD лучше BINARY FIXED или, например, decimal из .Net (C#), которое совсем не BCD
Здравствуйте, netch80, Вы писали: N>А что калькуляторы?
Да так, ничего, просто пример типичного отношения
От: netch80 Дата: 08.04.16 15:59
"Не смешите. Двоично-десятичная в 8080 (!) введена для работы с устройствами, которые вводят и выводят короткие числа в десятичном виде, как часы. Это был процессор для микроконтроллеров, и предложение использовать его для финансов встретило бы только дикое недоумение всех понимающих.
На этой "арифметике" вы нормально сделаете только сложение и вычитание — любых размеров, умножение и деление — только на одну цифру. Всё более сложное на ней выливается в дикий гемор, что проще делать через двоичку. Хорошо же средство для "финансов", что не может нормально вычислить несчастные 18% VAT или 3.3% сложного процента по кредиту.
В 8086 во всей линии вплоть до последних 32-разрядных версий это просто наследие, которое в линии IBM PC перестало быть ценным. В x86-64 его исключили как то, что уже лет 15 перед этим перестало быть хоть кому-то ценным".
От себя замечу, чтобы выводить короткие числа как часы никаких специальных команд не требуется
MOV AL,hour
MOV AH,10
DIV AH
ADD AL,'00'
Здравствуйте, pagid, Вы писали:
P>Так критерий истинности не книжки, где можно найти любые угодные ответы на любые вопросы, а практика. И BCD возможности не использовали ни компиляторостроители, ни писатели программ на ассемблере. Нужно ли его было выкидывать из 8080 , но в х86 его уже никто не использовал. Возможно потому, что BCD-арифметика совсем никому не нужна, возможно потому что её реализация в x86 это всего лишь повторение примитивнейших команд из калькуляторного i8008.
"Никто не использовал" — неверно. Просто ни в Си ни в Паскале никогда не было поддержки финансово-экономических вычислений. Но из этого не следует, что они не нужны. Был бы первым массовым транслятором на IBM-PC/XT был бы транслятор с PL/1 — никто бы сейчас не спрашивал, как вести точные расчеты.
"Примитивнейшие команды" — опять неверно. По большому счету все команды примитивнейшие, например, LOOP — зачем он нужен? Когда можно DEC ECX и JNZ и привет?
BCD команды упрощают реализацию точных вычислений, убирают лишние проверки. Кстати, то, что их выкинули из AMD-64 — ну, дураки, что сказать. Но все эти команды легко эмулируются . Вот если флаг переноса "A" выкинут, вот тогда действительно громоздко получится.
P>Только кто же этот Кобол видел Он остался только в глубоком легаси и только на Западе. Неужели ранее в СССР и сейчас не занимаются финансово-экономическими расчетами? И при этом успешно обходятся без Кобола и BCD встроенного в архитектуру процессоров.
Когда в СССР занимались финансово-экономическими расчетами, то прекрасно использовали Кобол, а затем PL/1
P>Новое поколение разработчиков Intel и старое поколение разработчиков AMD все прекрасно знает. И оценивает необходимость BCD в системе команд здраво.
кт>>Здесь это уже обсуждалось не раз, но опять в памяти остаются только калькуляторы. P>Совершенно верно, обсуждалось. И Вы тогда так и не объяснили чем BCD лучше BINARY FIXED или, например, decimal из .Net (C#), которое совсем не BCD
Армяне лучше, чем грузины. Чем лучше?...
Трудно объяснить, когда объяснения не воспринимаются.
Хорошо, попробую еще раз. BCD-представление чисел позволяет проводить точные вычисления для чисел, заданными десятичными дробями с некоторой аппаратной поддержкой для увеличения скорости. Да, не все числа можно точно представить десятичными дробями и этот подход не всеобъемлющ.
Самое главное — точность обеспечивается за счет увеличения длины (т.е. мантиссы) результата до необходимого значения.
Аналог — вычисления на бумажке столбиком.
Во всех других способах числа имеют заранее ограниченную максимальную длину мантиссы. Поэтому обеспечить точные вычисления при переполнении разрядной сетки не удается.
Еще раз — при BCD-представлении длина результата и, следовательно, точность вычислений ПРИНЦИПИАЛЬНО не ограничена. У всех остальных — принципиально ограничена.
Пусть Вас не смущает, что в PL/1 было ограничение в 15 цифр. Памяти тогда было мало, жаба всех задушила.
Ничто не мешает сейчас ввести числа, например, FIXED DECIMAL(2048,1024)
И вот этот, разработанный и отлаженный 60 лет назад механизм — взяли и выкинули. А взамен в C# очередная квадратура круга с числами заранее ограниченной длины.
Здравствуйте, кт, Вы писали:
кт>Армяне лучше, чем грузины. Чем лучше?... кт>Хорошо, попробую еще раз. BCD-представление чисел позволяет проводить точные вычисления для чисел, заданными десятичными дробями с некоторой аппаратной поддержкой для увеличения скорости. Да, не все числа можно точно представить десятичными дробями и этот подход не всеобъемлющ.
Эта "некоторая аппаратная поддержка" на современном процессоре будет тормозить в десятки раз по сравнению с вычислениями по 9 (максимум доступного прямолинейно без извратов) десятичными цифрами за раз, как можно делать на amd64 архитектуре. Именно поэтому она нахрен не нужна, а не потому, что где-то она не точно представляет 1/3.
кт>"Никто не использовал" — неверно. Просто ни в Си ни в Паскале никогда не было поддержки финансово-экономических вычислений. Но из этого не следует, что они не нужны. Был бы первым массовым транслятором на IBM-PC/XT был бы транслятор с PL/1 — никто бы сейчас не спрашивал, как вести точные расчеты.
Первый компилятор вряд ли при чём. Он потому и не был первым, что весь груз возможностей PL/1 — специфика, нужная ой не всем.
кт>>>Здесь это уже обсуждалось не раз, но опять в памяти остаются только калькуляторы. P>>Совершенно верно, обсуждалось. И Вы тогда так и не объяснили чем BCD лучше BINARY FIXED или, например, decimal из .Net (C#), которое совсем не BCD кт>Самое главное — точность обеспечивается за счет увеличения длины (т.е. мантиссы) результата до необходимого значения. кт>Аналог — вычисления на бумажке столбиком. кт>Во всех других способах числа имеют заранее ограниченную максимальную длину мантиссы. Поэтому обеспечить точные вычисления при переполнении разрядной сетки не удается. кт>Еще раз — при BCD-представлении длина результата и, следовательно, точность вычислений ПРИНЦИПИАЛЬНО не ограничена. У всех остальных — принципиально ограничена.
Во-первых, неправда, потому что на двоичке можно тоже получать любую точность. Не хочешь писать сам — возьми библиотечку типа GMP.
Во-вторых, современные BCD библиотеки не используют хлам в виде DAx, AAx команд.
кт>Пусть Вас не смущает, что в PL/1 было ограничение в 15 цифр. Памяти тогда было мало, жаба всех задушила. кт>Ничто не мешает сейчас ввести числа, например, FIXED DECIMAL(2048,1024) кт>И вот этот, разработанный и отлаженный 60 лет назад механизм — взяли и выкинули. А взамен в C# очередная квадратура круга с числами заранее ограниченной длины.
Зато в Java полноценный BigDecimal, и тоже без допотопных команд из древнего хлама.
Здравствуйте, кт, Вы писали:
кт>"Никто не использовал" — неверно. Просто ни в Си ни в Паскале никогда не было поддержки финансово-экономических вычислений.
В Си и Паскале, когда было надо, делали такие вычисления на целых числах.
кт>Но из этого не следует, что они не нужны. Был бы первым массовым транслятором на IBM-PC/XT был бы транслятор с PL/1 — никто бы сейчас не спрашивал, как вести точные расчеты.
У PL/1 не было шансов стать массовым транслятором для PC. Слишком он сложен. Включает до фига всего. Два типа операторов ввода-вывода, например. А PL/M, который я как-то однажды видел, показался мне сильно урезанным для того, чтобы на нем нормально программировать.
кт>BCD команды упрощают реализацию точных вычислений, убирают лишние проверки. Кстати, то, что их выкинули из AMD-64 — ну, дураки, что сказать. Но все эти команды легко эмулируются . Вот если флаг переноса "A" выкинут, вот тогда действительно громоздко получится.
А стоимость разработки, тестирования? А как с производительностью? Кто-то недавно ругался, что разработчики TCP/IP в 1971 году не сделали 128-битовый IP-адрес. Тут может быть похожая ситуация.
кт>Когда в СССР занимались финансово-экономическими расчетами, то прекрасно использовали Кобол, а затем PL/1
Даже ассемблер использовали. Я сам видел. И что?
кт>Самое главное — точность обеспечивается за счет увеличения длины (т.е. мантиссы) результата до необходимого значения.
Про BigDecimal уже сказали.
кт>И вот этот, разработанный и отлаженный 60 лет назад механизм — взяли и выкинули. А взамен в C# очередная квадратура круга с числами заранее ограниченной длины.
Здравствуйте, pagid, Вы писали:
P>Но тогда остается вопрос, как это числа так ловко "округлялись" при преобразовании в двойную точность. Какие-то процедуры стандартной библиотеки языка неявно вызывались? но что-то сомнения меня гложут, и всяко-разно тогда в Фортрановском компиляторе должно было быть сделано так же, что еще большие сомнения вызывает.
Обожди, я не понял. Какое преобразование? DEC FLOAT(16) — это и есть двойная точность. Разряды-то десятичные. А у BIN FLOAT(53) — двоичные. Вот деталей, что там с мантиссой, порядком, знаками — не вспомню. Не так уж плотно я с этим работал. К тому же это было так давно, что я даже сомневаюсь, было ли оно вообще.
Здравствуйте, кт, Вы писали:
кт>"Никто не использовал" — неверно. Просто ни в Си ни в Паскале никогда не было поддержки финансово-экономических вычислений.
Верно. Но финансово-экономические вычисления есть. И живут они на тех же процессорах, и все так же с использованием языков в которых "не поддержки", грустят наверно без поддержки. Впрочем, в 1С и аналогичных программах есть, но на нижнем уровне все равно С/С++. На С# есть, но совсем не BCD.
кт>Но из этого не следует, что они не нужны.
BCD судя по всему не нужен, сам по себе, как решение проблемы. Поддержка типов для денег в языках финансовых и учетно-бухгалтерских систем нужна, но она отлично работает без BCD в архитектуре процессора.
кт>Был бы первым массовым транслятором на IBM-PC/XT был бы транслятор с PL/1
Это совершенно негодный язык. Он "хорош" лишь тем, что в нем есть ВСЁ. Всё до включения чего в ЯВУ смогли додуматься в начале 60-х.
кт>никто бы сейчас не спрашивал, как вести точные расчеты.
Ага, идиотский дежурный вопрос связанный с непредставимостью в двоичной системе некоторых десятичных дробей не возникал бы. Но к точным расчетам он имеет очень косвенное отношение. Кстати, что для Вас эти самые сакральные "точные расчеты"?
кт>"Примитивнейшие команды" — опять неверно. По большому счету все команды примитивнейшие, например, LOOP — зачем он нужен? Когда можно DEC ECX и JNZ и привет? кт>BCD команды упрощают реализацию точных вычислений, убирают лишние проверки.
Примитивные по совершенно другой причине — они реализуют очень малую часть того, что необходимо для полноценной BCD арифметики. Другое дело, что BCD арифметика на уровне процессорных команд оказалась и не нужна, хоть полноценная, хоть примитивная.
кт>Кстати, то, что их выкинули из AMD-64 — ну, дураки, что сказать. Но все эти команды легко эмулируются
Осталось выяснить для чего их эмулировать.
кт>Когда в СССР занимались финансово-экономическими расчетами, то прекрасно использовали Кобол, а затем PL/1
Не знаю, PL/1 в СССР в том числе и для финансово-экономических расчетов застал и слегка со стороны видел, никаких следов Кобола не видел. Может слишком молод
кт>Армяне лучше, чем грузины. Чем лучше?...
Так это не сложнейший национальный вопрос , а очень простой — чем DECMAL FIXED(x,2) отличается от int32 или int64 при условии хранения сумм в копейках? Или DECMAL FIXED(x,4) от тех же целых при условии хранения в сотых долях копейки? Ответьте пожалуйста на него. Согласен ограничится той самой сакральной "точностью расчетов" не трогая других аспектов, например, того же быстродействия.
Более сложный вопрос — как "правильней" и лучше, в копейках или долях копейки, даже не задаю, хотя именно он имеет прямое и практическое отношение к точности и округлению в реальных финансово-экономических расчетах.
кт>Трудно объяснить, когда объяснения не воспринимаются.
Вот предыдущий вопрос как раз и был тестом на "воспринимаются"
кт>Хорошо, попробую еще раз. BCD-представление чисел позволяет проводить точные вычисления для чисел, заданными десятичными дробями с некоторой аппаратной поддержкой для увеличения скорости. Да, не все числа можно точно представить десятичными дробями и этот подход не всеобъемлющ.
Верно, не всегда, и настоящие практические, а не надуманные проблемы с точность начинаются как раз тогда, когда правильные и "точные" числа не делятся точно.
кт>Еще раз — при BCD-представлении длина результата и, следовательно, точность вычислений ПРИНЦИПИАЛЬНО не ограничена.
Так она и при двоичном представлении "не ограничена", примерно в том же смысле, а вот как раз при обсуждаемых финансово-экономических расчетах как раз должна быть ограничена.
кт>У всех остальных — принципиально ограничена.
Неверное утверждение.
кт>Ничто не мешает сейчас ввести числа, например, FIXED DECIMAL(2048,1024)
Зачем?
кт>И вот этот, разработанный и отлаженный 60 лет назад механизм — взяли и выкинули.
Выкинули за ненадобностью. В финансово-экономических расчетах нужна очень определенная точность, FIXED DECIMAL(2048,1024) это какой-то не смешной анекдот. В научных и инженерных расчетах совершенно без разницы не может быть число представлено "точно" в десятичном или двоичном виде, там под точностью подразумевают совсем другое.
кт>А взамен в C# очередная квадратура круга с числами заранее ограниченной длины.
Вот для чего Вам на практике потребовались или могли бы потребоваться числа неограниченной длинны, и как эту потребность могла удовлетворить именно BCD-арифметика, и чем в этом вашем случае было бы хуже двоичное представление?
Здравствуйте, Privalov, Вы писали:
P>Обожди, я не понял. Какое преобразование? DEC FLOAT(16) — это и есть двойная точность.
ТС в стартовом сообщении рассказывал, что на IBM/360 R4 при расширении в R8 очень хитро дополняется. Или может быть это только в ПЛ/1 было. Или не было.
уж слишком много вопросов и все они опять на тему BCD
на пару все-таки отвечу
P>Кстати, что для Вас эти самые сакральные "точные расчеты"?
При точных финансово-экономических расчетах после транзакций не должны появляться деньги из воздуха или пропадать из-за округлений.
Вот пример неправильного округления. Лимит возник из воздуха. http://files.rsdn.org/122727/limit.jpg
P>Так это не сложнейший национальный вопрос , а очень простой — чем DECMAL FIXED(x,2) отличается от int32 или int64 при условии хранения сумм в копейках? Или DECMAL FIXED(x,4) от тех же целых при условии хранения в сотых долях копейки? Ответьте пожалуйста на него. Согласен ограничится той самой сакральной "точностью расчетов" не трогая других аспектов, например, того же быстродействия. P>Более сложный вопрос — как "правильней" и лучше, в копейках или долях копейки, даже не задаю, хотя именно он имеет прямое и практическое отношение к точности и округлению в реальных финансово-экономических расчетах.
разница между decimal fixed и int32 в том, что, например, при умножении двух DECIMA(x,2) получится число типа DECIMAL(X+X,2+2+1) и транслятор это автоматически учитывает
а для int32 это все надо будет определять самому. Обратите внимание, что числа хранятся с двумя знаками (пусть копейками), а точность вычислений получается 4 знака (5 для комплексных) после точки.
И можно правильно и "точно" округлять простым присваиванием в переменную соответствующего типа, например опять в FIXED(x,2)
А если представлять сотые копейки как целые, то и точность будет только до сотых и округдения могут быть неправильные (как на фото)
BCD для этого удобен и отлично подходит. Он сравнительно компактен и нагляден. Его команды просто дополняют недостающие свойства "обычных" команд.
Например, сложение чисел из ESI и EDI, просто, быстро, универсально, не завязано на размер слова
CLC
M: LODSB
ADC AL,[EDI]
DAA
STOSB
LOOP M
Кстати, числа очень большой длины используются при поиске больших простых чисел.
А большие простые числа, например, сейчас используются в криптографии.
Здравствуйте, pagid, Вы писали:
P>>Обожди, я не понял. Какое преобразование? DEC FLOAT(16) — это и есть двойная точность. P>ТС в стартовом сообщении рассказывал, что на IBM/360 R4 при расширении в R8 очень хитро дополняется. Или может быть это только в ПЛ/1 было. Или не было.
Похоже, там была таки десятичная. Потому что в двоичной там были те же проблемы, хотя конкретные числа — другие.
Вот эта книга (даю официальную ссылку, хотя в интернете она на каждом углу уже файлом) содержит примеры типичных граблей плавучки в том числе и на базе S/360 (хотя старается обобщать).
Здравствуйте, кт, Вы писали:
кт>Кстати, числа очень большой длины используются при поиске больших простых чисел. кт>А большие простые числа, например, сейчас используются в криптографии.
И там используют высокооптимизированные библиотеки вроде GMP, в которых об использовании BCD речь не идёт даже в первоапрельскую шутку.
Здравствуйте, netch80, Вы писали:
N>Похоже, там была таки десятичная. Потому что в двоичной там были те же проблемы, хотя конкретные числа — другие.
Трудно сказать. Много воды утекло с тех пор. Но, согласно вот этому, я не сильно наврал, утверждая, что REAL FLOAT BINARY (53) и REAL FLOAT DECIMAL (16) — одно и то же и соответствует фортрановскому REAL*8. Значит, все-таки двоичная.
N>Вот эта книга (даю официальную ссылку, хотя в интернете она на каждом углу уже файлом) содержит примеры типичных граблей плавучки в том числе и на базе S/360 (хотя старается обобщать).
О, классика. У меня дома где-то второе издание лежит.
кт>>При точных финансово-экономических расчетах после транзакций не должны появляться деньги из воздуха или пропадать из-за округлений. P>Совершенно верно. Для этого достаточно считать, что все суммы представлены с точностью до копеек. Все — итоги любого расчета, суммы всех документах, на расчетных и бухалтерских счетах. И следить за тем, что бы одна и та же сумма в разных местах, например в в документах предоставляемых клиенту/контрагенту и во внутренней бухлалтерии были равна. Это обеспечивается не способом машинного представления чисел.
Опять я про Фому, а мне про Ерему.
Вот есть такая группа https://groups.google.com/forum/#!forum/comp.lang.pl1
Там среди завсегдатаев есть несколько пожилых преподавателей из калифорнийских ВУЗов
Они доброжелательно относятся к задающим вопросы.
Задайте им вопрос и, вероятно, они понятнее меня и с примерами объяснят, почему полвека назад очевидная идея при финансовых расчетах хранить центы, копейки и прочие фартинги в виде целых чисел была отвергнута, а введен специальный механизм расчетов, имеющий в Х86 даже аппаратную поддержку.
Что касается всяких умножений и делений, то это все давно отработано и транслятор не вешается. Вешатся должны те, у которых из ничего вдруг лимит в копейку получился
А еще через миллион транзакций это может быть уже не копейка. Вот тогда и объясняйте, что это допустимо.
Описание, как определяется точность при всех действиях входит в официальное описание языка, например, здесь:
Разверну секции в ответе.
кт>А вообще, мне эта тема надоела. Надоело спорить с людьми, никогда не видевшими реального использования BCD-команд в программах.
Интересный документ, спасибо. Не скажу, что полезный, всё-таки интерес чисто исторический, но перечитаю на досуге.
Только вот на вопрос коллеги pagid он не отвечает, и это странно, что ты этого не видишь.
Например, если надо деньги в копейках умножить на 17%, должна быть точность 2, 4 цифры после запятой, или сколько? Чисто по правилам главы F — должна 4 (я правильно прочёл?), а по целевой задаче — неизвестно, скорее всего нужно вернуться к копейкам (если это налог), но может быть полезно и усилить точность, если это вычисления для разбивки кредита на части.
Кстати, там ещё и ни слова про правила округления результатов, не представимых в целевом размере. А это ещё более важно. Если я не нашёл, хотя написано — укажи, пожалуйста, конкретную страницу.
кт>Что касается всяких умножений и делений, то это все давно отработано и транслятор не вешается. Вешатся должны те, у которых из ничего вдруг лимит в копейку получился кт>А еще через миллион транзакций это может быть уже не копейка. Вот тогда и объясняйте, что это допустимо.
Количество транзакций не имеет значения. Имеет значение то, что любые деньги должны быть распилены на части ровно, без потерь, а это значит, например, что 1.00 на 3 делится не иначе, как 0.33+0.33+0.34, при том, что 1.00/3 само по себе будет округлено до 0.33 даже в самой лучшей десятичной арифметике, а, значит, надо помнить, что после деления может результат не сойтись.
Как именно это будет обеспечено программистом — уже его дело и его заказчика. Должно быть чётко прописано ТЗ, что делать с лишними или недостающими копейками. Обычно такое делается итерациями вычитания; в случае двоичной арифметики есть методы оценки погрешности и корректировки по ходу, не буду тут подробно расписывать, но они неплохо проработаны.
В примере на экране телефона это было не проработано именно на уровне ТЗ, компьютер не виноват.
кт> а введен специальный механизм расчетов, имеющий в Х86 даже аппаратную поддержку.
А вот этот логический переход уже некорректен. Из расчётов с десятичной точкой никак не следует необходимость BCD, особенно стиля x86 и S/360.
BCD было хоть как-то выгодным ровно до того момента, когда стало доступным машинное умножение быстрее, чем O(N^2). Я не про Карацубу, Тоома-Кука и т.п., а про умножение одного слова на одно слово. На современном техническом уровне нарисовать умножение N*N сеткой из И+сумматоры — меньше чем копейки. Но даже на более древних методах уже в i286 умножение стало стоить чуть больше, чем собственно выборка команд и операндов.
кт>https://groups.google.com/forum/#!forum/comp.lang.pl1 кт>Там среди завсегдатаев есть несколько пожилых преподавателей из калифорнийских ВУЗов кт>Они доброжелательно относятся к задающим вопросы. кт>Задайте им вопрос и, вероятно, они понятнее меня и с примерами объяснят, почему полвека назад очевидная идея при финансовых расчетах хранить центы, копейки и прочие фартинги в виде целых чисел была отвергнута,
Это и так известно — не отвергнута. Но для того, чтобы не путать прикладных программистов финансовой области, которым слишком сложно и вообще не нужно объяснять, как оно работает внутри, маскировка под десятичную плавучку была введена на уровне языка.
Что-то жизнь в этой группе не очень кипит.
кт>Задайте им вопрос и, вероятно, они понятнее меня и с примерами объяснят, почему полвека назад очевидная идея при финансовых расчетах хранить центы, копейки и прочие фартинги в виде целых чисел была отвергнута, а введен специальный механизм расчетов, имеющий в Х86 даже аппаратную поддержку.
Сдается мне, полвека назад они просто экономили память. 2 десятичных цифры в байте vs одна цифра в байте. Уже в 80-х пользоваться форматом DEC FIXED не рекомендовалось. В финансивых расчетах использовали данные, объявленные с помощью шаблонов:
declare Price picture '$99V.99'
В каком формате хранится Price и как он округляется при вычислениях, я уже не помню.
Так это интересно только к исторической точки зрения.
А за ссылку на мануал по PL/1 спасибо, неравнодушен я к подобной истории.
кт>Там среди завсегдатаев есть несколько пожилых преподавателей из калифорнийских ВУЗов
Что и неудивительно.
кт>Задайте им вопрос и, вероятно, они понятнее меня и с примерами объяснят, почему полвека назад очевидная идея при финансовых расчетах хранить центы, копейки и прочие фартинги в виде целых чисел была отвергнута, а введен специальный механизм расчетов, имеющий в Х86 даже аппаратную поддержку.
Так они про ПЛ/1 объяснят, может оно все с той же исторической точки зрения интересно, но не применимо, да и отвлекать столь почтенных людей ради удовлетворения любопытства
кт>А вообще, мне эта тема надоела. Надоело спорить с людьми, никогда не видевшими реального использования BCD-команд в программах.
Но при этом реально занимающимися этими самыми финансово-экономические вычислениями, и может даже собаку на них съевшими.
