Здравствуйте, pagid, Вы писали:

P>·>Такие вещи нужно обсуждать с бизнес-аналистом или domain expert.
P>А если ТС сам себе бизнес-аналитик и этот самый "domain expert". Не все же на конвейере стоят.
Тогда он должен обсуждать с клиентами как они думают должно вычисляться чтобы они были довольны.

P>·>Все правила округления при вычислениях и порядок вычислений диктуется только бизнесом.
P>·>И никакое представление чисел тебе не поможет.
P>ТС интересуется не внесет ли представление чисел дополнительных проблем никак не связанных с бизнес-логикой.
Единственная такая проблема — перформанс, т.е. эффективность конкретных алгоритмов на конкретной платформе. Остальное — определяется бизнес-логикой.
Да и собственно перформанс тоже задаётся бизнес-логикой. Мы например, в критическом месте для финансов использовали double вместо BigDecimal — ибо в данном случае было важнее дать результат быстрее, а не точнее.

P>·>В финансах люди обычно используют десятичные числа, поэтому и в компьютере вычисления должны быть десятичными, с учётом требуемых способов округления.
P>У ТС свои особенности, в его продукте задействован (и похоже не на последних ролях) некий "фреймворк" работающий с double.
P>И инженеры и ученые тоже используют десятичные числа, но это не значит, что при научных и инженерных расчетах компьютере вычисления должны быть десятичными.
Не должны, но могут, это просто другая область. Например, строители могут считать в миллиметрах. Т.е. просто другая предметная область, правила вычислений те же.

P>·>какой ответ правильный? А оба могут быть правильные — зависит от требований бизнеса.
P>Первый, если мы в России.
Да это не от страны зависит, вроде. Например, продажа по цене $99.99/кг, и продав 10кг сотне клиентов это не то же самое что продажа 100кг десяти. Т.е. налог может считаться не на единицу товара, а на транзакцию.

Здравствуйте, кт, Вы писали:

кт>Кобол уже решил вопросы финансовых расчетов, почему его решения не взять в другие языки?

Потому что эти решения до сих пор используются на Коболе. Перетаскивать их куда-то еще просто не нужно.

Здравствуйте, Privalov, Вы писали:

P>Потому что эти решения до сих пор используются на Коболе. Перетаскивать их куда-то еще просто не нужно.

Тогда почему возникают такие ветки?
Очередной программист узнал, что числа IEEE-754 представляются неточно?
И начинается очередное вычисление квадратуры круга.
А если бы механизм точных вычислений был бы просто перенесен в современные языки (как из Кобола в ПЛ/1), то и вопросов бы не было — для финансово-экономических расчетов применяй то-то и то-то.

Здравствуйте, кт, Вы писали:

кт>Очередной программист узнал, что числа IEEE-754 представляются неточно?
Да.
кт>И начинается очередное вычисление квадратуры круга.
Да. А на самом деле оно не нужно.

кт>А если бы механизм точных вычислений был бы просто перенесен
Не нравится мне это Ваше "механизм точных вычислений", очень уж напоминает смятение вышеупомянутого программиста только узнавшего...

кт>в современные языки (как из Кобола в ПЛ/1), то и вопросов бы не было — для финансово-экономических расчетов применяй то-то и то-то.
Почему именно Кобол и ПЛ/1, чем не устраивает например decimal из C# ?

По поводу статьи.
Если так

ТотСамыйТочныйТип Sum;
ПростоЧисло k=3;
СноваНеТочно = (Sum/k)*k;

Вновь займетесь вычислением квадратуры круга?

Здравствуйте, pagid, Вы писали:

P>Вновь займетесь вычислением квадратуры круга?

Как раз я ей не занимаюсь и не пытаюсь использовать для финансовых расчетов мантиссу и порядок.
А пример с 1/3 непоказателен. В большинстве случаев в финансах нужны не рациональные дроби, а проценты (и особенно сложные проценты). Как раз они прекрасно представляются в десятичном виде. Автор старой статьи пытался донести для чего в IA-32 введена двочная арифметика, Float-арифметика и BCD-арифметика.
Двоичная — для "обычных" вычислений
float — для научных
двоично-десятичная — для финансовых.

Не считайте программистов 60-х и 70-х за дикарей с луком и стрелами.

P.S. в статье объяснялась, чем не устраивает Decimal С#

Здравствуйте, кт, Вы писали:

P>>Статья несколько "в сторону". В сторону ПЛ/1.

кт>дело вовсе не в PL/1 (на самом деле не в Коболе?)
кт>Дело в том, что эти вопросы давно решены, в том числе и на аппаратном уровне — двоично-десятичная арифметика.
кт>И вставлены в процессоры.

Уже не вставлены. В x86-64 двоично-десятичные команды (AA? и DA?) отменены. Можно их эмулировать, но снова на чистой бинарке.

кт> А теперь начинают велосипед изобретать. Кобол уже решил вопросы финансовых расчетов, почему его решения не взять в другие языки?

Расскажите подробнее, пожалуйста, как он именно их решил. Тем более, что статья по ссылке говорила про PL/1, а не Cobol.

Здравствуйте, pagid, Вы писали:

кт>>в современные языки (как из Кобола в ПЛ/1), то и вопросов бы не было — для финансово-экономических расчетов применяй то-то и то-то.
P>Почему именно Кобол и ПЛ/1, чем не устраивает например decimal из C# ?

Ну меня он не устраивает сразу по нескольким параметрам:

1. Никак не решаются вопросы фиксации особых ситуаций и/или перевод их в исключения.
Что будет при переполнении? Недополнении? Потере значащих цифр?

2. Вместо следования уже планировавшимся на момент его введения IEEE754 decimal floats, изобрели свой велосипед. Причём с кучей странных решений. Например, почему порядок только от 0 до 28?

Здравствуйте, netch80, Вы писали:

N>Уже не вставлены. В x86-64 двоично-десятичные команды (AA? и DA?) отменены. Можно их эмулировать, но снова на чистой бинарке.
Вновь пришедшие инженеры в Интел никогда не видели двоично-десятичных расчетов Они и операцию INTO выкинули (идиоты).

Про "чистую бинарку" не понял, вот, например, эмуляции DAA

;--------------- ЭМУЛЯЦИЯ DAA, ЗАПРЕЩЕННОЙ В РЕЖИМЕ X86-64 ------------

PUBLIC DAA_X86_64:
PUSH RDX,RAX
LAHF
MOV EDX,EAX ;OLD CF И OLD AL
AND AH,NOT 1B ;СБРОСИЛИ CF

;---- ОБРАБОТКА МЛАДШЕЙ ТЕТРАДЫ ----

TEST AH,10000B ;ЕСЛИ ЕСТЬ AF
JNZ @
PUSH RAX
AND AL,0FH
CMP AL,9 ;ИЛИ ЕСЛИ ЦИФРА БОЛЬШЕ 9
POP RAX
JBE M2270
@: ADD AL,6 ;КОРРЕКЦИЯ ЦИФРЫ
OR AH,10000B ;УСТАНАВЛИВАЕМ AF

;---- ОБРАБОТКА СТАРШЕЙ ТЕТРАДЫ ----

M2270:TEST DH,1B ;ЕСЛИ СТОЯЛ OLD CF
JNZ @
CMP DL,99H ;ИЛИ НУЖЕН ПЕРЕНОС
JBE M2271
@: OR AH,1B ;УСТАНАВЛИВАЕМ CF
ADD AL,60H ;КОРРЕКЦИЯ ТЕТРАДЫ

;---- ПИШЕМ ГОТОВЫЙ БАЙТ И ВОССТАНАВЛИВАЕМ РЕГИСТРЫ И ФЛАГИ ----

M2271:SAHF
MOV [ESP],AL
POP RAX,RDX
RET


кт>> А теперь начинают велосипед изобретать. Кобол уже решил вопросы финансовых расчетов, почему его решения не взять в другие языки?

N>Расскажите подробнее, пожалуйста, как он именно их решил. Тем более, что статья по ссылке говорила про PL/1, а не Cobol.

В PL/1 ничего нового не добавили, взяли из Кобола.

Представьте, что у вас нет компьютера, а есть ручка и бумага. Можно же сосчитать нужные проценты и т.п., умножая и складывая столбиком.
При этом числа точные, хотя и не обязательно целые. Именно это и было разработано для Кобола — точное представление в десятичном виде, практически в виде текста на бумаге.

Двоично-десятичные расчеты — аналог расчетов на бумаге. Это было реализовано 60 лет назад. И американские бухгалтеры не жаловались

Здравствуйте, кт, Вы писали:

кт>Как раз я ей не занимаюсь и не пытаюсь использовать для финансовых расчетов мантиссу и порядок.
кт>А пример с 1/3 непоказателен. В большинстве случаев в финансах нужны не рациональные дроби, а проценты (и особенно сложные проценты). Как раз они прекрасно представляются в десятичном виде. Автор старой статьи пытался донести для чего в IA-32 введена двочная арифметика, Float-арифметика и BCD-арифметика.
кт>Двоичная — для "обычных" вычислений
кт>float — для научных
кт>двоично-десятичная — для финансовых.

Не смешите. Двоично-десятичная в 8080 (!) введена для работы с устройствами, которые вводят и выводят короткие числа в десятичном виде, как часы. Это был процессор для микроконтроллеров, и предложение использовать его для финансов встретило бы только дикое недоумение всех понимающих.
На этой "арифметике" вы нормально сделаете только сложение и вычитание — любых размеров, умножение и деление — только на одну цифру. Всё более сложное на ней выливается в дикий гемор, что проще делать через двоичку. Хорошо же средство для "финансов", что не может нормально вычислить несчастные 18% VAT или 3.3% сложного процента по кредиту.

В 8086 во всей линии вплоть до последних 32-разрядных версий это просто наследие, которое в линии IBM PC перестало быть ценным. В x86-64 его исключили как то, что уже лет 15 перед этим перестало быть хоть кому-то ценным.

кт>Не считайте программистов 60-х и 70-х за дикарей с луком и стрелами.

Это вы их такими, похоже, считаете, если выдвигаете идеи использовать x86 BCD для финансов. Они использовали S/360, S/370 и аналоги.
В этой линии есть, например, такие команды процессора, как конверсия из bin в dec и обратно, сложение, вычитание, умножение и деление, округление, которые работают над числами в памяти, например, AP — сложить два упакованных (2 цифры на байт) числа длиной до 16 байт (31 цифра и знак). Вот это — у программистов 60-70-х. А лук и стрелы в этой области начались позже, с массовым расползанием персоналок...

Здравствуйте, кт, Вы писали:

кт>Здравствуйте, netch80, Вы писали:

N>>Уже не вставлены. В x86-64 двоично-десятичные команды (AA? и DA?) отменены. Можно их эмулировать, но снова на чистой бинарке.
кт>Вновь пришедшие инженеры в Интел никогда не видели двоично-десятичных расчетов Они и операцию INTO выкинули (идиоты).

1. Это были AMD, а не Intel.
2. С современными архитектурами никакого смысла в этих командах не стало. Не считайте их настолько идиотами. Команды типа DAA нужны только процессорам, которые не умеют быстрой арифметики, для работы, в которой от ввода числа в текстовом десятичном выводе до его вывода выполняется максимум десяток одноцифровых операций. Ни первое, ни второе не соответствуют современному железу и современным задачам.

кт>Про "чистую бинарку" не понял, вот, например, эмуляции DAA

А теперь померяйте время работы этого всего кошмара для 16 цифр и сравните со временем одного сложения в double.

кт>>> А теперь начинают велосипед изобретать. Кобол уже решил вопросы финансовых расчетов, почему его решения не взять в другие языки?
N>>Расскажите подробнее, пожалуйста, как он именно их решил. Тем более, что статья по ссылке говорила про PL/1, а не Cobol.
кт>В PL/1 ничего нового не добавили, взяли из Кобола.

Если речь про идею numeric с двумя фиксированными размерами, это раньше Кобола.

кт>Представьте, что у вас нет компьютера, а есть ручка и бумага. Можно же сосчитать нужные проценты и т.п., умножая и складывая столбиком.
кт>При этом числа точные, хотя и не обязательно целые. Именно это и было разработано для Кобола — точное представление в десятичном виде, практически в виде текста на бумаге.

кт>Двоично-десятичные расчеты — аналог расчетов на бумаге. Это было реализовано 60 лет назад. И американские бухгалтеры не жаловались

Именно такие расчёты сейчас ведут в Fixed и не требуют никаких BCD в процессоре.

Здравствуйте, netch80, Вы писали:

N>Не смешите. Двоично-десятичная в 8080 (!) введена для работы с устройствами, которые вводят и выводят короткие числа в десятичном виде, как часы. Это был процессор для микроконтроллеров, и предложение использовать его для финансов встретило бы только дикое недоумение всех понимающих.
N>На этой "арифметике" вы нормально сделаете только сложение и вычитание — любых размеров, умножение и деление — только на одну цифру. Всё более сложное на ней выливается в дикий гемор, что проще делать через двоичку. Хорошо же средство для "финансов", что не может нормально вычислить несчастные 18% VAT или 3.3% сложного процента по кредиту.

N>В 8086 во всей линии вплоть до последних 32-разрядных версий это просто наследие, которое в линии IBM PC перестало быть ценным. В x86-64 его исключили как то, что уже лет 15 перед этим перестало быть хоть кому-то ценным.

Боюсь, Вы не понимаете смысла BCD-арифметики. Она не для коротких чисел, а для чисел любой длины. Точно так же как операции ADC и SBB позволяют за счет учета переноса реализовать арифметику люблй длины, например, миллион знаков. И это можно было делать даже на 8080 (была версия PL/1 и для такого процессора) и ответ получается правильный

Здравствуйте, кт, Вы писали:

кт>Боюсь, Вы не понимаете смысла BCD-арифметики. Она не для коротких чисел, а для чисел любой длины.

Это Вы не понимаете, что она нахрен не нужна для чисел "любой длины" в таком виде. Настолько неэффективна, что дешевле перевести в двоичку и всё подсчитать в ней, чем маяться дурью по одной десятичной цифре.

кт> Точно так же как операции ADC и SBB позволяют за счет учета переноса реализовать арифметику люблй длины, например, миллион знаков.

Там хотя бы по 32/64, а не по 4 (в лучшем случае 8, не для всех действий).

N>Это Вы не понимаете, что она нахрен не нужна для чисел "любой длины" в таком виде.

На такие доводы у меня нет аргументов. Сдаюсь.

Здравствуйте, кт, Вы писали:

N>>Это Вы не понимаете, что она нахрен не нужна для чисел "любой длины" в таком виде.
кт>На такие доводы у меня нет аргументов. Сдаюсь.

Теоретически аргументы у вас есть. Выпустить новую архитектуру, которая бы имела такие операции. Или убедить принять даже как специализированное расширение к существующей. Например, вон RISC-V сейчас очень активно пилят, можно присоединиться. У них ещё ничего окончательно не застыло, реализаций в ASIC нет, максимум что есть — трансляция в FPGA — легко переписывается. Попробуйте убедить
На практике же, я думаю, реальность такого результата — 0%.

В AArch64, например, куча неожиданных решений — типа того, что нет отдельной операции целочисленного умножения, а есть целочисленная FMA(!) и для умножения в качестве слагаемого задаётся null register. То есть видно, что авторы крепко перепланировали всю реализацию. Но intBCD у них нет Как нет и в любой архитектуре толще, чем 8-битный камень уровня "нам надо на чём-то будильник построить", разработанной хотя бы в 1970. (В S/370 и позже группа команд intBCD сохраняется только как наследие проклятого прошлого.)

Так что — пробуйте. Если получится, будет прикольно. Но — не верю

Здравствуйте, ·, Вы писали:

·>Я наблюдал, например, что налоговка использует округления в пользу налогоплательщика — налогооблагаемая прибыль округляется вниз, а налоговые вычеты — вверх.

А еще, например, авансовые платежи в налоговую округляются не до копеек, а до целых рублей.

Здравствуйте, Ops, Вы писали:

Ops>А еще, например, авансовые платежи в налоговую округляются не до копеек, а до целых рублей.
И все налоги уже давно округляются до рублей. При этом рекомендуется использовать обычное арифметическое округление.

Здравствуйте, pagid, Вы писали:

Ops>>А еще, например, авансовые платежи в налоговую округляются не до копеек, а до целых рублей.
P>И все налоги уже давно округляются до рублей. При этом рекомендуется использовать обычное арифметическое округление.

Мнэээ... 14.50 округлять рекомендовано до 14 или 15?
А 15.50?

Здравствуйте, netch80, Вы писали:

N>Мнэээ... 14.50 округлять рекомендовано до 14 или 15?
N>А 15.50?

Мне показалось, что в России в нормативных документах способ округления прямо не устанавливается. Но разумеется принято округлять 14.50 до 15, а 15.50 до 16. Если где-то программы округляют по "импортным" правилам вряд ли кого-то это волнует или вызывает какие-то недоразумения.

Здравствуйте, Ops, Вы писали:

Ops>·>Я наблюдал, например, что налоговка использует округления в пользу налогоплательщика — налогооблагаемая прибыль округляется вниз, а налоговые вычеты — вверх.
Ops>А еще, например, авансовые платежи в налоговую округляются не до копеек, а до целых рублей.
Да, в спеках UK-налоговой там шесть видов округлений: до пенсов, до фунтов * вверх, вниз, банковское.

Вопрос — возможно ли реализовать эти округления используя тип double?

Здравствуйте, ·, Вы писали:

·>Тогда он должен обсуждать с клиентами как они думают должно вычисляться чтобы они были довольны.
ТС с нам обсуждал вопрос реализации не касающийся пользователей — какое внутреннее представление в его случае будет оптимальным/разумным. С вопросом в какой момент и каким способом нужно округлять результаты расчетов обращаться конечно же нужно к клиенту.

·>Да это не от страны зависит, вроде. Например, продажа по цене $99.99/кг, и продав 10кг сотне клиентов это не то же самое что продажа 100кг десяти.
Разумеется не то же самое. НДС считается отдельно по каждому документу. Оно наверно везде так. В России и отдельно по каждой строке (наименованию товара) документа. Ставки могут быть разные. Но не на единицу товара, а на все количество. Тут не возьмусь судить, как в других странах. Еще в России есть особенности связанные с заполнением налоговой декларации, но там возможные небольшие отклонения связанные с округлениями допустимы и никого не волнуют.