【发布时间】：2011-03-12 21:08:43
【问题描述】：
我意识到我们应该使用BigDecimal 来表示所有货币价值，但是以美元表示的股票价格呢？
我注意到主要供应商的数据馈送 API 使用 double 类型来表示股票报价。有谁知道为什么？
这是否意味着我的应用程序可以使用 double 类型来存储来自这些供应商的股票报价？
【问题讨论】：
【发布时间】：2011-03-12 21:08:43
【问题描述】：
不将二进制浮点用于货币的原因是货币使用小数，人们（和会计法规）期望对其执行的算术运算具有特定的十进制行为 - 二进制浮点不提供。
但是，股票报价供稿通常不用于会计。它们被显示、比较、用作各种图表分析指标或交易算法的输入——所有这些都比会计更接近科学应用，并且不需要小数行为或精度。相反，由于数据量大，存储效率和性能是相关的，BigDecimal 真的很烂。
【讨论】：
-
另一个很好的答案。 BigDecimal 只是不用于引号。
我在外地工作。从精度的角度来看，BigDecimal 显然是理想的，但从性能的角度来看却很糟糕。在某些情况下双倍是一种选择（特别是在处理正常股票价格时，双倍很容易 - 采取适当的预防措施 - 能够代表我经常处理的所有股票交易所的整个价格范围）。
另一个选项是，如果您知道相关交易所使用的 DP 范围，则使用定点和普通 int 或 long。举一个我熟悉的例子，Xetra（德国电子交易所）目前最多有 3 个小数位。使用 3dp，您可以使用正常的 int 表示最高 2,147,483.647 的价格。对单个价格很好，不能代表一天的总交易量。
这完全是一个问题，即您接收到什么数据、这些数据的精度是多少以及您如何处理它。
【讨论】：
我拒绝将 BigDecimal 用于货币价值（一般*）。使用设计 用于货币的数据类型（具有最小精度，例如美元的密耳）并知道如何处理其他规则。这也可用于防止美元“意外”转换为日元等。 Joda Money 或 timeandmoney 就是两个这样的例子。
虽然 BigDecimal 在解决固定精度方面远优于双精度数，但 IMOHO 仍然不是正确的货币表示。 （BigDecimal 可能是后端 [或者它可以完全替换为另一个 impl。]，作为前端它不能充分代表域。）
编码愉快。
*正如其他人所说，这取决于用途。
【讨论】：
我个人会坚持BigDecimal。供应商 使用双精度有点令人不安，但是您没有理由传播他们的错误。您将从“稍微糟糕”的数据开始，但至少您不会在您对这些值执行的任何操作中引入更多意外行为。
您可能想与供应商交谈并了解为什么他们使用双打...
【讨论】：
-
只要你除了传递/显示它们（在股票价格中很常见）之外没有对值做任何事情，保持双精度值就没有坏处。尽管我不愿不同意在 Dev Days London 上发表如此精彩演讲的人（如果我没记错的话，包括关于浮点的部分）......
-
无法在 Web 服务/REST Api 中表示
BigDecimal。如果不是 double，那么用这种格式表示钱的最佳方式是什么？ -
@The Elite Gentleman：我可能会提供一个 API，它使用不变文化的十进制字符串（即一种几乎可以用任何语言解析的方式）。
-
这确实取决于你用它做什么。如果您不打算对其执行任何操作而不是显示它，那么您显然不会丢失任何信息。
对此的猜测：
我注意到主要供应商的数据馈送 API 使用 double 类型来表示股票报价。有谁知道为什么？
当这样的 API 使用基于文本的格式（如 XML 或 JSON）时，传输的数据实际上不是双精度数，而是十进制数 - 而十进制数就是这里的意思。在某些 API 中，通常 double 是唯一支持十进制数（点后有数字）的数据类型。
当您收到双倍的股票价格并想要“以金钱方式”计算它时，请确保您知道它有多少小数位数（在点之后）（应该有 - 不是来自双倍，而是来自股票价格的类型），然后用这个比例将其转换为 BigDecimal（或您用于货币计算的任何内容）。
【讨论】：