java 为什么 Bigdecimal(double d) 结构仍然存在？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1056722/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why is the Bigdecimal(double d) construction still around?
提问by Ryan Fernandes
I've noticed substantial pain over this constructor (even here on Stack Overflow). People use it even though the documentation clearly states:
我已经注意到这个构造函数的巨大痛苦（即使在 Stack Overflow 上也是如此）。即使文档明确指出，人们仍然使用它：
The results of this constructor can be somewhat unpredictablehttp://java.sun.com/javase/6/docs/api/java/math/BigDecimal.html#BigDecimal(double)
此构造函数的结果可能有些不可预测http://java.sun.com/javase/6/docs/api/java/math/BigDecimal.html#BigDecimal(double)
I've even seen a JSR-13being APPROVEDwith a recommendation stating:
Existing specifications that might be deprecated: We propose deprecating the BigDecimal(double) constructor, which currently gives results that are different to the Double.toString() method.
可能被弃用的现有规范：我们建议弃用 BigDecimal(double) 构造函数，它当前给出的结果与 Double.toString() 方法不同。
Despite all this, the constructor has not yet been deprecated.
尽管如此，构造函数尚未被弃用。
I'd love to hear any views on this.
我很想听听对此有何看法。
采纳答案by Tom Hawtin - tackline
Deprecation is deprecated. Parts of APIs are only marked deprecated in exceptional cases.
弃用已弃用。部分 API 仅在特殊情况下才被标记为已弃用。
So, run FindBugs as part of your build process. FindBugs has a detector PlugIn API and is also open source (LGPL, IIRC).
因此，将 FindBugs 作为构建过程的一部分运行。FindBugs 有一个检测器插件 API，也是开源的（LGPL、IIRC）。
回答by coobird
Considering the behavior of BigDecimal(double)is correct, in my opinion, I'm not too sure it really would be such a problem.
考虑到 的行为BigDecimal(double)是正确的，在我看来，我不太确定它真的会出现这样的问题。
I wouldn't exactly agree with the wording of the documentation in the BigDecimal(double)constructor:
我不会完全同意BigDecimal(double)构造函数中文档的措辞：
The results of this constructor can be somewhat unpredictable. One might assume that writing
new BigDecimal(0.1)in Java creates aBigDecimalwhich is exactly equal to0.1(an unscaled value of1, with a scale of1), but it is actually equal to0.1000000000000000055511151231257827021181583404541015625.
此构造函数的结果可能有些不可预测。人们可能会假设
new BigDecimal(0.1)用 Java编写创建的 aBigDecimal完全等于0.1（一个未缩放的值1，缩放为1），但它实际上等于0.1000000000000000055511151231257827021181583404541015625。
(Emphasis added.)
（加了重点。）
Rather than saying unpredictable, I think the wording should be unexpected, and even so, this would be unexpected behavior for those who are not aware of the limitations of representation of decimal numbers with floating point values.
与其说不可预测，我认为措辞应该是出乎意料的，即便如此，对于那些不知道用浮点值表示十进制数的局限性的人来说，这也是出乎意料的行为。
As long as one keeps in mind that floating point values cannot represent all decimal values with precision, the value returned by using BigDecimal(0.1)being 0.1000000000000000055511151231257827021181583404541015625actually makes sense.
只要一个人守记住，浮点值不能代表精确所有十进制值，该值通过返回的BigDecimal(0.1)是0.1000000000000000055511151231257827021181583404541015625实际上是有意义的。
If the BigDecimalobject instantiated by the BigDecimal(double)constructor is consistent, then I would argue that the result is predictable.
如果构造函数BigDecimal实例化的对象BigDecimal(double)是一致的，那么我认为结果是可预测的。
My guess as to why the BigDecimal(double)constructor is not being deprecated is because the behavior can be considered correct, and as long as one knows how floating point representations work, the behavior of the constructor is not too surprising.
我对为什么BigDecimal(double)构造函数没有被弃用的猜测是因为这种行为可以被认为是正确的，只要知道浮点表示是如何工作的，构造函数的行为就不会太令人惊讶。
回答by mP.
That particular constructor, like all floating point operations, is an approximation. It's not really broken, it just has shortcomings.
Just do your research, approach it with care, and you won't get any surprises. You run into exactly the same thing when assigning decimal literals to doubles/floats.
与所有浮点运算一样，那个特定的构造函数是一个近似值。不是真的坏，只是有缺点。
只要做你的研究，小心地接近它，你就不会得到任何惊喜。将十进制文字分配给双精度数/浮点数时，您遇到了完全相同的问题。
