Java中double类型精度丢失的问题

Question

为什么使用add2方法的结果是错误的？Double.toString(d1)为什么能保持double的精度不丢失？

    public static double add(double d1, double d2) {
        BigDecimal bd1 = new BigDecimal(Double.toString(d1));
        BigDecimal bd2 = new BigDecimal(Double.toString(d2));
        return bd1.add(bd2).doubleValue();
    }
    
    public static double add2(double d1, double d2) {
        BigDecimal bd1 = new BigDecimal(d1);
        BigDecimal bd2 = new BigDecimal(d2);
        return bd1.add(bd2).doubleValue();
    }

    public static void main(String[] args) {
        double d1 = 1.0000002;
        double d2 = 0.0000002;
        System.out.println(Double.toString(d1));
        System.out.println("d1 + d2 = " + (d1 + d2)); // 1.0000003999999998
        System.out.println("d1 + d2 = " + add(d1, d2)); // 1.0000004
        System.out.println("d1 + d2 = " + add2(d1, d2)); // 1.0000003999999998
    }

PS：引出一个概念问题：

double d = XXXX.XXXXXX;
System.out.println(d);    //这里总是不会丢失精度的，为什么？

Answer 1

BigDecimal在用double做入參的時候，二進位無法精確地表示十進位小數，編譯器讀到字串"0.0000002"和「1.0000002」之後，必須把它轉成8個位元組的double值，也就是1.0000001999999998947288304407265968620777130126953125类似这种。
所以，运行的时候，实际传给BigDecimal构造函数的真正的数值是1.0000001999999998947288304407265968620777130126953125 。
BigDecimal在用String做入參的時候，能夠正確地把字串轉換成真正精確的浮點數。

System.out.println部分，如果入參是string，那麼直接輸出，如果入參是其他類型，那麼會呼叫Object.toString方法進行轉換之後進行輸出。而Double.toString會使用一定的精度來四捨五入double，然後再輸出。

BigDecimal構造方法上的註解就寫了這個問題：

 The results of this constructor can be somewhat unpredictable.
     * One might assume that writing {@code new BigDecimal(0.1)} in
     * Java creates a {@code BigDecimal} which is exactly equal to
     * 0.1 (an unscaled value of 1, with a scale of 1), but it is
     * actually equal to
     * 0.1000000000000000055511151231257827021181583404541015625.
     * This is because 0.1 cannot be represented exactly as a
     * {@code double} (or, for that matter, as a binary fraction of
     * any finite length).  Thus, the value that is being passed
     * <i>in</i> to the constructor is not exactly equal to 0.1,
     * appearances notwithstanding.
     
     The {@code String} constructor, on the other hand, is
 * perfectly predictable: writing {@code new BigDecimal("0.1")}
 * creates a {@code BigDecimal} which is <i>exactly</i> equal to
 * 0.1, as one would expect.  Therefore, it is generally
 * recommended that the {@linkplain #BigDecimal(String)
 * <tt>String</tt> constructor} be used in preference to this one.
 
 

補充說明一下：
Double.toString這個方法輸出的是一個String，而且會進行四捨五入處理。 Double.toString这个方法输出的是一个String，而且会进行四舍五入处理。
new BigDecimal(Double.toString(d1))这个入参在处理完毕之后是一个String，调用的是BigDecimal(String val)new BigDecimal(Double.toString(d1))這個入參在處理完畢之後是一個String，呼叫的是BigDecimal(String val)這個建構方法。
源碼裡BigDecimal(String val)這個方法是會將val處理成char[]陣列：

this(val.toCharArray(), 0, val.length());

然後呼叫BigDecimal(char[] in)這個構造方法。

而new BigDecimal(d1)呼叫的是 BigDecimal(double val)，這個方法進來之後第一件事就是

long valBits = Double.doubleToLongBits(val); 

把入參轉換成二進制，所以會造成精度損失。

double相加造成的精度遺失和上面的情況一樣，先轉成bit之後再計算，然後精度遺失。 。