Общие стратегии иметь дело с погрешностями округления в мягком интенсивном валютой?

Использовать округление Банковского. Вы округлите до ближайших двух пенни.

http://www.xbeat.net/vbspeed/i_BankersRounding.htm

Вместо этого вы можете округлить до ближайших двух пенни. Таким образом, 22,5 округляет до 22, но 23,5 округляет до 24. 23,1 и 22,9 округляются до 23. Однако первоначальный алгоритм банкира более популярен.

Все зависит от приложения. Надеюсь, не так уж много ситуаций, когда требуется округление. Например, перевод денег с одного счета на другой не требует округления.

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

Я немного (совсем немного) работал с денежными суммами, и мне было очень любопытно, какая стратегия используется в моей компании ...

Оказывается, мы используем двойной , но они подумали об этом.

Дело в том, что суммы, с которыми мы имеем дело, не так уж велики (скажем, менее 10 КБ), и нам нужно не более 3 цифр после десятичной дроби, всего 7 значащих цифр.

Поскольку мы используем 64-битное программное обеспечение (и C ++), тип double предлагает достаточно значащих цифр для количества операций, которые мы выполняем:)

Если вам нужна более высокая точность, есть алгоритмы для использовать (например, при добавлении нескольких денег), но лично я думаю, что суть проблемы в большей степени связана с:

• преобразованием одних денег в другие, которое, конечно, постоянно меняется;
• проблемы с печатью, с некоторыми деньгами, не требующими десятичной дроби, для других требуется не более 2-х и т. д.

Не могли бы вы расширить круг операций, которые выполняете?

То, что вам следует делать, может быть основано на правилах рынка или юрисдикции, в которых вы работаете. Например, ценообразование облигаций на австралийском рынке требует, чтобы вы округлили некоторые промежуточные операции до 8 знаков после запятой. Окончательная цена указана с точностью до определенного числа десятичных знаков (3, я думаю, не в порядке).

Если вы имеете дело с бухгалтерским приложением, я ожидаю, что соответствующие стандарты бухгалтерского учета для вашей правовой среды, возможно, будут диктовать это.

При записи финансовых данных возникает множество проблем с округлением. Первая проблема - это возможность хранить и извлекать точные десятичные числа

• . Большинство баз данных предлагают десятичный тип данных, в котором вы можете указать количество цифр до и после десятичной точки (валюты также различаются по количеству десятичных цифр, с которыми я имел дело валюты с 0, 2, 3 десятичными цифрами)
• при работе с этими данными, и вы хотите избежать любых неожиданных ошибок округления на стороне приложения, вы можете использовать BCD в качестве общего подхода, или вы можете использовать целые числа для представления любого фиксированного десятичного представления или смешивания вашего собственного

. Если эта первая проблема решена, то никакое сложение (или вычитание) не может привести к ошибкам округления. То же самое и с умножением на целое число.

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

Например, если ваш денежный формат допускает 2 десятичных знака и вы хотите сохранить транзакцию, в которой записываются балансы дебета от 10 до 3 равных частей, вы можете сохранить ее только как

10.00  
-3.33  
-3.33  
-3.33  

и

-0.01 

(ошибка округления)

Это Ожидается, что проблема возникнет независимо от выбора типа хранилища данных, и о которой необходимо позаботиться, если вы хотите, чтобы ваши учетные записи были сбалансированы. Эта ситуация в основном возникает при делении (или умножении на нецелые числа, которые имеют много значащих цифр).

Один из способов справиться с этим - проверить, уравновешиваются ли ваши данные после таких операций, и распознать допустимую разницу в округлении в отличие от ситуации с ошибкой.

РЕДАКТИРОВАТЬ: Что касается ссылок на литературу, то этот кажется интересным и не слишком длинным и касается довольно широкой аудитории с интересными сценариями.

Никогда не храните денежные значения в формате double или float - используйте int или long, поскольку в двоичном формате невозможно точно хранить 0,1.