税率是否需要存储为整数？答案

【问题标题】：Do tax rates need to be stored as integers?税率是否需要存储为整数？
【发布时间】：2014-10-03 03:28:26
【问题描述】：

我了解由于舍入误差问题，货币值应作为整数存储和处理。这对我来说很有意义，我明白了（我认为）。

但是税率呢？是否有任何理由需要将税率（不是税额，税率，例如 6.5 或 8.125）存储为整数而不是小数？

如果我将税率存储为整数，如何将税率应用于交易中的美元金额？如果我以 6.5% 的税率计算 10000 * 1.065 ($100.00 * 1.065)，那么在数据库中将 6.5% 存储为 6500 而不是 6.500 会有什么好处？我不认为一次将一个数字乘以或除以 100 会导致舍入错误。

我如何存储税率重要吗？

【问题讨论】：

浮点运算出现问题 (here is one explanation)。如果您将税率存储为 decimal 而不是浮点数，并确保公式的结果是 decimal 精度值而不是浮点数，我不知道会有任何舍入误差。你在什么环境下做这个？更多信息和用例/示例，有人可以提供更多指导。

【解决方案1】：

首先，并不是说您不应该使用小数。这是您不应该在想要获得精确值的地方使用浮点数。并非所有小数都是浮点数；请参阅 C# 中的小数数据类型或 Java 中的 java.math.BigDecimal。

其次，10 的幂特别容易受到奇怪的浮点问题的影响，因为浮点的实现方式会导致无限重复小数除以 10 的幂。请参阅this question。这是一个简单的例子：

groovy:000> f = 0.1F // make a floating point number
===> 0.1
groovy:000> f * 100 
===> 10.000000149011612

发生这种情况是因为 0.1 的表示是被截断的重复小数。这里 REPL 撒谎了，真正的 f 不是 0.1，而是 0.100000001490116119384765625。

你可以绕过这个然后继续，there's an argument for doing that：

要解决此问题，您需要提供适当的舍入。有了钱，这很容易，因为您知道有多少小数位是合适的，除非您有 70 万亿美元，否则您不会得到足够大的舍入误差，您无法纠正它。

但使用 BigDecimals：

groovy:000> d = new BigDecimal("0.1")
===> 0.1
groovy:000> d * 100
===> 10.0

使用定点小数，这样您就可以准确地知道自己拥有的数字。如果您的语言没有固定小数（如 Javascript），you may have to fall back on integers。

【讨论】：

知道了。那么，对于货币而言，我总是希望将定点数乘以定点数是否正确？
这是一个完全独立的问题，但我现在完全困惑为什么我似乎看到这么多人提倡将货币价值存储为“美分”而不是美元金额，例如10000 而不是 100.00。
@Jason：差不多。 vanillajava.blogspot.com/2011/08/double-your-money-again.html 有一篇有趣的文章，提出了相反的观点。但你必须知道你在做什么。
@Jason：我不知道它的上下文是什么，但是在 javascript 中没有固定的小数，所以整数更容易。