"新BigDecimal(13.3D)"导致不精确的"13.3000000000000007105 .."？

Java是如何BigDecimal痛苦的？

Double d = 13.3D;

BigDecimal bd1 = new BigDecimal(d);
BigDecimal bd2 = new BigDecimal(String.valueOf(d));


System.out.println("RESULT 1: "+bd1.toString());
System.out.println("RESULT 2: "+bd2.toString());

RESULT 1: 13.300000000000000710542735760100185871124267578125
RESULT 2: 13.3

是否存在需要结果1的情况？我知道Java 1.5改变了toString()方法,但这是预期的后果吗？

我也意识到BigDecimal有doubleValue()等等,但我正在使用的库有用地使用了一个toString(),我无法改变:-(

干杯.

那么,API确实解决了构造函数中这种明显的不一致性BigDecimal(double val):

这个构造函数的结果可能有点不可预测.有人可能会假设在Java中编写新的BigDecimal(0.1)会创建一个BigDecimal,它恰好等于0.1(未缩放值为1,标度为1),但它实际上等于0.1000000000000000055511151231257827021181583404541015625.这是因为0.1 不能精确地表示为double(或者,就此而言,作为任何有限长度的二进制分数).因此,传递给构造函数的值并不完全等于0.1,尽管有外观.

另一方面,String构造函数是完全可预测的:写入新的BigDecimal("0.1")会创建一个BigDecimal,它正好等于0.1,正如人们所期望的那样.因此,通常建议优先使用String构造函数.

当double必须用作BigDecimal的源时,请注意此构造函数提供了精确的转换; 它不会产生与使用Double.toString(double)方法将double转换为String然后使用BigDecimal(String)构造函数相同的结果.要获得该结果,请使用static valueOf(double)方法.

故事的道德:痛苦似乎是自己造成的,只是使用new BigDecimal(String val)或BigDecimal.valueOf(double val)代替=)

你的问题与之无关BigDecimal,并且所有Double内容都无法准确表示13.3,因为它在内部使用二进制分数.

所以你的错误是在第一行引入的.第一个BigDecimal简单地保留它,同时String.valueOf()做一些鱼腥的圆形,导致第二个具有所需的内容,几乎通过运气.

您可能想要了解浮点值的实现方式(IEEE 754-1985).突然间,一切都会变得清澈透明.

这不是故障BigDecimal- 这是故障double.BigDecimal准确地表示了确切的值d.String.valueOf只显示几个小数位的结果.