舍入标准 - 财务计算

Gua*_*mez 29 rounding-error bankers-rounding rounding financial

我很好奇在财务数据的计算方面存在任何"舍入"标准.我最初的想法是仅在数据呈现给用户(表示层)时执行舍入.

如果"舍入"数据然后用于进一步计算,应该使用"圆形"数字还是"原始"数字?有人有建议吗?

请注意,我知道不同的舍入方法,即银行家舍入等.

Mic*_*rdt 15

第一个也是最重要的规则:使用十进制数据类型,永远不要使用二进制浮点类型.

当执行完全舍入时,可以通过法规强制执行,例如欧元和国家货币之间的转换.

如果没有这样的规则,我会以高精度进行所有计算,并且仅用于呈现,即不使用舍入值进行进一步计算.这应该产生最佳的整体精度.

  • @Joe:不,100.67几乎总是更好,因为它是人们所期望的 - 更重要的是,使用十进制类型确保100.01 + 100.07 = 100.08而不是200.07999999999998 (9认同)
  • 我不确定"不使用舍入值进行进一步计算",例如,第1项的税是0.012美元,第2项是0.015美元,所以当你在声明中显示它们时,0.01美元和0.01美元,从视觉上你可以得到0.02美元的总税,但是如果你用0.025美元的精度添加它们,当你显示你得到$ 0.03时 (4认同)
  • @Joe:这些都没有改变二进制浮点数对于财务计算是不可接受的事实,因为它们根本无法准确地表示大多数小数部分,并且会以完全不可预测的方式引入舍入错误.幸运的是,这是一个非问题,因为任何值得使用的十进制类型将提供远远超过2个小数位(如果需要). (3认同)
  • 二进制浮点数比十进制数更好,精度太低.$100⅔更好地代表基数2为"100.66666666666 ?????" 而在基数10中为"100.67".但是给定足够的十进制精度,我同意十进制数据类型通常更好. (2认同)
  • 产生人们期望的时间是在展示时间,并且当在那里进行舍入时(例如'%0.2f'),人们将看到他们期望的东西.如果你正在进行中间计算,我认为截断/舍入到只有2位数的精度是不合适的.(当然这取决于手头的计算.每日利息计算四舍五入可能每天为账户增加0.00.但客户发票不需要15个精度.) (2认同)

Joe*_*erg 14

我刚刚在我工作的财务软件公司问了一个greybeard大型机程序员,他说没有众所周知的标准,这取决于程序员的实践.

虽然自1906年以来统计学家已经意识到四舍五入问题,但很难找到支持它的财务标准.

根据这一情况,"欧盟委员会的报告"欧元的引入和货币的四舍五入 表明,以前没有标准的方法来进行银行业务的四舍五入."

通常,无论您使用何种基础(base-2或base-10),都使用对称舍入模式.

这将避免计算过程中的系统偏差.

这种模式是Round-Half-Even-Even,也称为"银行家舍入".

使用允许您指定数字上下文明确性的语言工具,包括舍入和截断模式.例如,Python的decimal模块.C库所做的隐式假设可能不适合您的计算.

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


Ste*_*edl 5

令人沮丧的是,这方面没有明确的标准,既可以指导程序员,也可以作为法庭辩护。只是对工资单进行“定期”四舍五入可能会导致工资单上少付几美分,这是劳工律师像裂缝一样吃掉的东西。

虽然基本工资率可能只指定两位小数(“你的工资是 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
Run Code Online (Sandbox Code Playgroud)

你为什么从我的客户那里偷走 5 美分?可悲的是,我不是在开玩笑。

当您以全精度值计算但显示截断版本时,这会变得更加不舒服:您执行上面的第一个计算,但在工资单上只显示 23.37 美元的费率。

现在工资单的计算与一分钱无关,现在你必须解释它,但即使它对员工有利,也足以让劳工律师闻到水中的血腥味并开始寻找其他东西。

一种方法是始终支持员工,而不是顺其自然,因此永远不会有系统性盗窃工资的指控。