DecimalFormat即使在明確設置時也使用不正確的RoundingMode

Question

爲什麼此DecimalFormat未按預期使用RoundingMode.HALF_UP進行舍入，以及應該如何獲得預期輸出？可以用DecimalFormat完成嗎？

DecimalFormat df = new DecimalFormat("0.0"); 

df.setRoundingMode(RoundingMode.HALF_UP); 

df.format(0.05); // expecting 0.1, getting 0.1 
df.format(0.15); // expecting 0.2, getting 0.1 << unexpected 

df.format(0.06); // expecting 0.1, getting 0.0 << unexpected 

我從this question看到的答案，特別是this answer，但似乎只四捨五入到整數的時候工作。

我的JDK是8.0.110，我的JRE是8.0.730.2

（以下使用Java 8回答）

你所看到的問題來自於指定代碼 「0.15」 或 「0.05」

Answer 1

，當它表示爲雙精度時略小於0.15。檢查了這一點

DecimalFormat df = new DecimalFormat("#.#"); 

df.setRoundingMode(RoundingMode.HALF_UP); 

BigDecimal bd = new BigDecimal(0.15); 
System.out.println("bd=" + bd); 
System.out.println(df.format(0.15)); // expecting 0.1, getting 0.1 
bd = new BigDecimal(0.05); 
System.out.println("bd=" + bd); 
System.out.println(df.format(0.05)); 
bd = new BigDecimal(0.06); 
System.out.println("bd=" + bd); 
System.out.println(df.format(0.06)); 

這段代碼的輸出是

bd=0.1499999999999999944488848768742172978818416595458984375 
0.1 
bd=0.05000000000000000277555756156289135105907917022705078125 
0.1 
bd=0.059999999999999997779553950749686919152736663818359375 
0.1 

一個可能的解決方案（如果你確實需要它來圓的正確方法）是使用BigDecimal.valueOf創造價值。例如

BigDecimal bd = BigDecimal.valueOf(0.15); 
System.out.println("bd=" + bd); 
System.out.println(df.format(bd)); // expecting 0.1, getting 0.1 
bd = BigDecimal.valueOf(0.05); 
System.out.println("bd=" + bd); 
System.out.println(df.format(bd)); 
bd = BigDecimal.valueOf(0.06); 
System.out.println("bd=" + bd); 
System.out.println(df.format(bd)); 

現在將產生

bd=0.15 
0.2 
bd=0.05 
0.1 
bd=0.06 
0.1 

順便說一句，因爲可怕的袋熊指出，掩碼設定爲0.0，而不是＃，＃將0.6 0。但我認爲這是後來編輯然後當我開始看着它。使用 ＃。＃。

Answer 2

當你

df.format(0.15); 

實際上有取整運算。顯而易見的是你用df.format要求的那個，但是在編譯時會有一個更早的。

十進制值0.15不能表示爲雙精度型。雙打只能表示分母是二的冪的分母，就像十進制符號只能表示分母是十的冪的分母。當你寫0.15，編譯器幾輪這最接近的值表示爲一個雙，和值恰好是

0.1499999999999999944488848768742172978818416595458984375 

這df.format正確幾輪下來。它不在0.1和0.2之間，所以HALF_UP舍入模式並不重要。

至於

df.format(0.06); // expecting 0.1, getting 0.0 << unexpected 

如果你看到是，這是一個錯誤。它看起來像匹配one linked by ScaryWombat，據報道固定在8u40和8u45。使用8u51的Ideone的測試顯示了正確的行爲。更新你的Java應該可以解決這個問題。

Answer 3

我認爲答案是IEEE Standard for Floating-Point Arithmetic (IEEE 754). Wiki文章在Rounding rules部分有一個很好的例子。你也可以閱讀9.1 of Introduction to Java的章節，瞭解更多關於浮點的內容。 BigDecimal通過在BigInteger中存儲未調用的值解決了大部分這些短小問題，精度和範圍分別存儲在整數字段中。