Стандарты округления - финансовые расчеты

Question

Мне любопытно, что существуют какие-либо "стандарты округления", когда речь идет о вычислении финансовых данных. Мои первоначальные мысли - выполнять округление только тогда, когда данные представляются пользователю (уровень представления). *

Если для дальнейших расчетов используются «округленные» данные, следует ли использовать «округленную» или «необработанную»? У кого-нибудь есть совет?

Обратите внимание, что мне известны различные методы округления, т. Е. Округление банкиров и т. Д.

Answer 1

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

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

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

Answer 2

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

Несмотря на то, что статистики знакомы с проблемой округления, по крайней мере, с 1906 года, трудно найти финансовый стандарт, одобряющий ее.

Согласно этому заседанию е, "отчет Европейской комиссии Введение евро и округление валютных сумм предполагает, чтоРанее не было стандартного подхода к округлению в банковской сфере ».

В общем, используйте симметричный режим округления независимо от того, на какой базе вы работаете (база-2 или база-10).

Это позволит избежать систематического смещения во время вычислений.

Таким режимом является округление до половины, даже известное как «округление банкиров».

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

http://en.wikipedia.org/wiki/Rounding#Rounding_to_integer

Answer 3

Я не видел существования «единого стандарта, который бы управлял ими всеми» - существует любое количество правил округления (как вы упомянули), и они, кажется, вступают в игру на основе отраслевого / клиентского / и кода валюты http://en.wikipedia.org/wiki/ISO_4217) - поскольку не все используют 2 знака после запятой, проблема становится еще более сложной. В конце дня ваш клиент должен указать правила, которые он хочет внедрить ...

Answer 4

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

Хотя базовая ставка заработной платы вполне может быть указана только в двух десятичных разрядах («Вы наняты по 22,71 долл. США / час»), такие вещи, как смешанное сверхурочное время (определяемое путем усреднения нескольких ставок за период), в конечном итоге приводят к эффективной почасовая ставка $ 23,37183475 / час.

Как вы платите за это сверхурочно?

15 hours x 23.37183475 x 1.5 = $525.87 rounded from $525.86628187
15 hours x 23.37       x 1.5 = $525.82

ПОЧЕМУ ВЫ украли у моего клиента пять центов? К сожалению, я не шучу по этому поводу.

Это становится еще более неудобным, когда вы вычисляете с полной точностью, но отображаете усеченную версию: вы делаете первое вычисление выше, но отображаете только 23,37 $ для ставки на платежном квитанции.

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

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

Answer 5

Рассмотрите возможность использования масштабированных целых чисел.

Другими словами, храните целые числа копеек вместо дробных чисел в долларах.