Здравствуйте, кт, Вы писали:
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'
Здравствуйте, кт, Вы писали:
кт>Здравствуйте, 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. Может, недостаточно чётко выразился.
Здравствуйте, 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 (хотя старается обобщать).
О, классика. У меня дома где-то второе издание лежит.
Здравствуйте, кт, Вы писали:
кт>уж слишком много вопросов и все они опять на тему 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 оно всегда будет намного меньше, даже при полноценной аппаратной реализации, если кто-то вдруг таки сделает её. Только двоичные целые.
кт>>При точных финансово-экономических расчетах после транзакций не должны появляться деньги из воздуха или пропадать из-за округлений. 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-команд в программах.
Но при этом реально занимающимися этими самыми финансово-экономические вычислениями, и может даже собаку на них съевшими.
, но в х86 его уже никто не использовал. Возможно потому, что BCD-арифметика совсем никому не нужна, возможно потому что её реализация в x86 это всего лишь повторение примитивнейших команд из калькуляторного i8008.
Он остался только в глубоком легаси и только на Западе. Неужели ранее в СССР и сейчас не занимаются финансово-экономическими расчетами? И при этом успешно обходятся без Кобола и BCD встроенного в архитектуру процессоров.
