java中浮點數的比較（double, float)(轉)

時間 2019-11-13

原文原文鏈接

問題的提出：
若是咱們編譯運行下面這個程序會看到什麼？html

    public static void main(String args[]){
        System.out.println(0.05+0.01);
        System.out.println(1.0-0.42);
        System.out.println(4.015*100);
        System.out.println("BigDecimal:"+new BigDecimal(Double.toString(4.015)).multiply(new BigDecimal(Double.toString(100))));
        System.out.println(123.3/100);
    }

你沒有看錯！結果確實是
0.060000000000000005
0.5800000000000001
401.49999999999994
BigDecimal:401.5000
1.2329999999999999
Java中的簡單浮點數類型float和double不可以進行運算。不光是Java，在其它不少編程語言中也有這樣的問題。在大多數狀況下，計算的結果是準確的，可是多試幾回（能夠作一個循環）就能夠試出相似上面的錯誤。如今終於理解爲何要有BCD碼了。
這個問題至關嚴重，若是你有9.999999999999元，你的計算機是不會認爲你能夠購買10元的商品的。
在有的編程語言中提供了專門的貨幣類型來處理這種狀況，可是Java沒有。如今讓咱們看看如何解決這個問題。

四捨五入
咱們的第一個反應是作四捨五入。Math類中的round方法不能設置保留幾位小數，咱們只能象這樣（保留兩位）：
public double round(double value){
    return Math.round(value*100)/100.0;
}
很是不幸，上面的代碼並不能正常工做，給這個方法傳入4.015它將返回4.01而不是4.02，如咱們在上面看到的
4.015*100=401.49999999999994
所以若是咱們要作到精確的四捨五入，不能利用簡單類型作任何運算
java.text.DecimalFormat也不能解決這個問題：
System.out.println(new java.text.DecimalFormat("0.00").format(4.025));
輸出是4.02

BigDecimal
在《Effective Java》這本書中也提到這個原則，float和double只能用來作科學計算或者是工程計算，在商業計算中咱們要用 java.math.BigDecimal。BigDecimal一共有4個夠造方法，咱們不關心用BigInteger來夠造的那兩個，那麼還有兩個，它們是：
BigDecimal(double val)
          Translates a double into a BigDecimal.
BigDecimal(String val)
          Translates the String repre sentation of a BigDecimal into a BigDecimal.
上面的API簡要描述至關的明確，並且一般狀況下，上面的那一個使用起來要方便一些。咱們可能想都不想就用上了，會有什麼問題呢？等到出了問題的時候，才發現上面哪一個夠造方法的詳細說明中有這麼一段：
Note: the results of this constructor can be somewhat unpredictable. One might assume that new BigDecimal(.1) is exactly equal to .1, but it is actually equal to .1000000000000000055511151231257827021181583404541015625. This is so because .1 cannot be represented exactly as a double (or, for that matter, as a binary fraction of any finite length). Thus, the long value that is being passed in to the constructor is not exactly equal to .1, appearances nonwithstanding.
The (String) constructor, on the other hand, is perfectly predictable: new BigDecimal(".1") is exactly equal to .1, as one would expect. Therefore, it is generally recommended that the (String) constructor be used in preference to this one.
原來咱們若是須要精確計算，非要用String來夠造BigDecimal不可！在《Effective Java》一書中的例子是用String來夠造BigDecimal的，可是書上卻沒有強調這一點，這也許是一個小小的失誤吧。java

解決方案
如今咱們已經能夠解決這個問題了，原則是使用BigDecimal而且必定要用String來夠造。
可是想像一下吧，若是咱們要作一個加法運算，須要先將兩個浮點數轉爲String，而後夠形成BigDecimal，在其中一個上調用add方法，傳入另外一個做爲參數，而後把運算的結果（BigDecimal）再轉換爲浮點數。你可以忍受這麼煩瑣的過程嗎？下面咱們提供一個工具類Arith來簡化操做。它提供如下靜態方法，包括加減乘除和四捨五入：
public static double add(double v1,double v2)
public static double sub(double v1,double v2)
public static double mul(double v1,double v2)
public static double div(double v1,double v2)
public static double div(double v1,double v2,int scale)
public static double round(double v,int scale)
附錄
源文件Arith.java：
import java.math.BigDecimal;
/**
* 因爲Java的簡單類型不可以精確的對浮點數進行運算，這個工具類提供精
* 確的浮點數運算，包括加減乘除和四捨五入。
*/
public class Arith{
    //默認除法運算精度
    private static final int DEF_DIV_SCALE = 10;
    //這個類不能實例化
    private Arith(){
    }

    /**
     * 提供精確的加法運算。
     * @param v1 被加數
     * @param v2 加數
     * @return 兩個參數的和
     */
    public static double add(double v1,double v2){
        BigDecimal b1 = new BigDecimal(Double.toString(v1));
        BigDecimal b2 = new BigDecimal(Double.toString(v2));
        return b1.add(b2).doubleValue();
    }
    /**
     * 提供精確的減法運算。
     * @param v1 被減數
     * @param v2 減數
     * @return 兩個參數的差
     */
    public static double sub(double v1,double v2){
        BigDecimal b1 = new BigDecimal(Double.toString(v1));
        BigDecimal b2 = new BigDecimal(Double.toString(v2));
        return b1.subtract(b2).doubleValue();
    }
    /**
     * 提供精確的乘法運算。
     * @param v1 被乘數
     * @param v2 乘數
     * @return 兩個參數的積
     */
    public static double mul(double v1,double v2){
        BigDecimal b1 = new BigDecimal(Double.toString(v1));
        BigDecimal b2 = new BigDecimal(Double.toString(v2));
        return b1.multiply(b2).doubleValue();
    }

    /**
     * 提供（相對）精確的除法運算，當發生除不盡的狀況時，精確到
     * 小數點之後10位，之後的數字四捨五入。
     * @param v1 被除數
     * @param v2 除數
     * @return 兩個參數的商
     */
    public static double div(double v1,double v2){
        return div(v1,v2,DEF_DIV_SCALE);
    }

    /**
     * 提供（相對）精確的除法運算。當發生除不盡的狀況時，由scale參數指
     * 定精度，之後的數字四捨五入。
     * @param v1 被除數
     * @param v2 除數
     * @param scale 表示表示須要精確到小數點之後幾位。
     * @return 兩個參數的商
     */
    public static double div(double v1,double v2,int scale){
        if(scale<0){
            throw new IllegalArgumentException(
                "The scale must be a positive integer or zero");
        }
        BigDecimal b1 = new BigDecimal(Double.toString(v1));
        BigDecimal b2 = new BigDecimal(Double.toString(v2));
        return b1.divide(b2,scale,BigDecimal.ROUND_HALF_UP).doubleValue();
    }

    /**
     * 提供精確的小數位四捨五入處理。
     * @param v 須要四捨五入的數字
     * @param scale 小數點後保留幾位
     * @return 四捨五入後的結果
     */
    public static double round(double v,int scale){
        if(scale<0){
            throw new IllegalArgumentException(
                "The scale must be a positive integer or zero");
        }
        BigDecimal b = new BigDecimal(Double.toString(v));
        BigDecimal one = new BigDecimal("1");
        return b.divide(one,scale,BigDecimal.ROUND_HALF_UP).doubleValue();
    }
}編程

http://blog.csdn.net/pttaag/article/details/5912171c#

最近在項目中碰到了一個業務邏輯計算,代碼以下(示例代碼)app

double val1 = ...;編程語言

double val2 = ...,ide

double dif = ...,函數

if (Math.abs(val1 - val2-dif) == 0){工具

//do thingspost

}

結果發現有一組數據:61.5,60.4,1.1沒法達到正確的結果.有經驗的開發人員一眼就能夠發現問題所在,也知道應該採用以下的方式修改代碼(產品模式下要進行代碼的抽取和封裝):

double exp = 10E-10;

if (Math.abs(val1 - val2-dif)>-1*exp && Math.abs(val1 - val2-dif)<exp){

//do things

}

那爲何上面代碼中"Math.abs(val1 - val2-dif) == 0"的值爲何會是false呢?這就引伸到java的一個基礎問題,即java中浮點數的存儲機制.

Java 中的浮點數分爲單精度和雙精度數，也就是float和double.

float在內存中跟int同樣，佔4個字節，32 bit.

第1個bit表示符號,0表示正數,1表示負數,這個很好理解,不用多管.

第2-9個bit表示指數,一共8位(能夠表示0-255),這裏的底數是2,爲了同時表示正數和負數,這裏要減去127的偏移量.這樣的話範圍就是(-127到128),

另外全0和全1做爲特殊處理,因此直接表示-126到127.

剩下的23位表示小數部分,這裏23位表示了24位的數字,由於有一個默認的前導1(只有二進制纔有這個特性).

最後結果是:(-1)^(sign) * 1.f * 2^(exponent)

這裏:sign是符號位,f是23bit的小數部分,exponent是指數部分,最後表示範圍是(由於正負數是對稱的,這裏只關心正數)

2^(-126) ~~ 2(1-2^(-24)) * 2^127

這個還不是float的取值範圍,由於標準中還規定了非規格化表示法,另外還有一些特殊規定.

非規格化表示:

當指數部分全0並且小數部分不全0時表示的是非規格化的浮點數,由於這裏默認沒有前導1,而是0.

取值位0.f * 2^(-126),表示範圍位 2^(-149)~~ (1-2^(-23)) * 2^(-126) 這裏沒有考慮符號.這裏爲何是-126而不是-127? 若是是-127的話,那麼最大表示爲

2^(-127)-2^(-149),很顯然2^(-127) ~~2^(-126) 就無法表示了.

其餘特殊表示

1.當指數部分和小數部分全爲0時,表示0值,有+0和-0之分(符號位決定),0x00000000表示正0,0x80000000表示負0.

2.指數部分全1,小數部分全0時,表示無窮大,有正無窮和負無窮,0x7f800000表示正無窮,0xff800000表示負無窮.

3.指數部分全1,小數部分不全0時,表示NaN,分爲QNaN和SNaN,Java中都是NaN.

結論:

能夠看出浮點數的取值範圍是:2^(-149)~~(2-2^(-23))*2^127,也就是Float.MIN_VALUE和Float.MAX_VALUE.

References:

http://blog.csdn.net/treeroot/archive/2004/09/05/95071.aspx

http://hi.baidu.com/520miner/blog/item/698266ed9ee000d7b31cb1aa.html

http://blog.csdn.net/running8063/article/details/4093261

Java中關於 BigDecimal 的一個致使double精度損失的"bug"

背景

在博客噁心的0.5四捨五入問題一文中看到一個關於 0.5 不能正確的四捨五入的問題。主要說的是 double 轉換到 BigDecimal 後，進行四捨五入得不到正確的結果：

public class BigDecimalTest { public static void main(String[] args){ double d = 301353.05; BigDecimal decimal = new BigDecimal(d); System.out.println(decimal);//301353.0499999999883584678173065185546875 System.out.println(decimal.setScale(1, RoundingMode.HALF_UP));//301353.0  } }

輸出的結果爲：

301353.0499999999883584678173065185546875
301353.0

這個結果顯然不是咱們所指望的，咱們但願的是獲得 301353.1 。

緣由

容許明眼人一眼就看出另外問題所在——BigDecimal的構造函數 public BigDecimal(double val) 損失了double 參數的精度，最後才致使了錯誤的結果。因此問題的關鍵是：BigDecimal的構造函數 public BigDecimal(double val) 損失了double 參數的精度。

解決之道

由於上面找到了緣由，因此也就很好解決了。只要防止了 double 到 BigDecimal 的精度的損失，也就不會出現問題。

1）很容易想到第一個解決辦法：使用BigDecimal的以String爲參數的構造函數：public BigDecimal(String val) 來替代。

public class BigDecimalTest { public static void main(String[] args){ double d = 301353.05; System.out.println(new BigDecimal(new Double(d).toString())); System.out.println(new BigDecimal("301353.05")); System.out.println(new BigDecimal("301353.895898895455898954895989")); } }

輸出結果：

301353.05
301353.05
301353.895898895455898954895989

咱們看到了沒有任何的精度損失，四捨五入也就確定不會出錯了。

2）BigDecimal的構造函數 public BigDecimal(double val) 會損失了double 參數的精度，這個也許應該能夠算做是 JDK 中的一個 bug 了。既然存在bug，那麼咱們就應該解決它。上面的辦法是繞過了它。如今咱們實現本身的 double 到 BigDecimal 的轉換，而且保證在某些狀況下能夠徹底不損失 double 的精度。

import java.math.BigDecimal; public class BigDecimalUtil { public static BigDecimal doubleToBigDecimal(double d){ String doubleStr = String.valueOf(d); if(doubleStr.indexOf(".") != -1){ int pointLen = doubleStr.replaceAll("\\d+\\.", "").length(); // 取得小數點後的數字的位數 pointLen = pointLen > 16 ? 16 : pointLen; // double最大有效小數點後的位數爲16 double pow = Math.pow(10, pointLen); 
　　　　　　　long tmp = (long)(d * pow); return new BigDecimal(tmp).divide(new BigDecimal(pow)); } return new BigDecimal(d); } public static void main(String[] args){ // System.out.println(doubleToBigDecimal(301353.05)); // System.out.println(doubleToBigDecimal(-301353.05)); // System.out.println(doubleToBigDecimal(new Double(-301353.05))); // System.out.println(doubleToBigDecimal(301353)); // System.out.println(doubleToBigDecimal(new Double(-301353))); double d = 301353.05;//5898895455898954895989;  System.out.println(doubleToBigDecimal(d)); System.out.println(d); System.out.println(new Double(d).toString()); System.out.println(new BigDecimal(new Double(d).toString())); System.out.println(new BigDecimal(d)); } }

輸出結果：

301353.05
301353.05
301353.05
301353.05
301353.0499999999883584678173065185546875

上面咱們本身寫了一個工具類，實現了 double 到 BigDecimal 的「無損失」double精度的轉換。方法是將小數點後有有效數字的double先轉換到小數點後沒有有效數字的double，而後在轉換到 BigDecimal ，以後使用BigDecimal的 divide 返回以前的大小。

上面的結果看起來好像十分的完美，可是實際上是存在問題的。上面咱們也說到了「某些狀況下能夠徹底不損失 double 的精度」，咱們先看一個例子：

    public static void main(String[] args){ double d = 301353.05; System.out.println(doubleToBigDecimal(d)); System.out.println(d); System.out.println(new Double(d).toString()); System.out.println(new BigDecimal(new Double(d).toString())); System.out.println(new BigDecimal(d)); System.out.println("========================="); d = 301353.895898895455898954895989; System.out.println(doubleToBigDecimal(d)); System.out.println(d); System.out.println(new Double(d).toString()); System.out.println(new BigDecimal(new Double(d).toString())); System.out.println(new BigDecimal(d)); System.out.println(new BigDecimal("301353.895898895455898954895989")); System.out.println("========================="); d = 301353.46899434; System.out.println(doubleToBigDecimal(d)); System.out.println(d); System.out.println(new Double(d).toString()); System.out.println(new BigDecimal(new Double(d).toString())); System.out.println(new BigDecimal(d)); System.out.println("========================="); d = 301353.45789666; System.out.println(doubleToBigDecimal(d)); System.out.println(d); System.out.println(new Double(d).toString()); System.out.println(new BigDecimal(new Double(d).toString())); System.out.println(new BigDecimal(d)); }

輸出結果：

301353.05
301353.05
301353.05
301353.05
301353.0499999999883584678173065185546875
=========================
301353.89589889544
301353.89589889545
301353.89589889545
301353.89589889545
301353.895898895454593002796173095703125
301353.895898895455898954895989
=========================
301353.46899434
301353.46899434
301353.46899434
301353.46899434
301353.4689943399862386286258697509765625
=========================
301353.45789666
301353.45789666
301353.45789666
301353.45789666
301353.4578966600238345563411712646484375
咱們能夠看到：咱們本身實現的 doubleToBigDecimal 方法只有在 double 的小數點後的數字位數比較少時(好比只有5,6位)，才能保證徹底的不損失精度。

在 double 的小數點後的數字位數比較多時，d * pow 會存在精度損失，因此最終的結果也會存在精度損失。因此若是小數點後的位數比較多時，仍是使用 BigDecimal的 String 參數的構造函數爲好，只有在小數點後的位數比較少時，才能夠採用本身實現的 doubleToBigDecimal 方法。

由於咱們看到原始的double的轉換以後的BigDecimal的數字的最後一位一個時5，一個是4，緣由是在上面的轉換方法中：

long tmp = (long)(d * pow);

這一步可能存在很小的精度損失，由於 d 是一個 double ，d * pow 以後仍是一個 double(可是小數點以後都是0了，因此到long的轉換沒有精度損失) ，因此會存在很小的精度損失(double的計算老是有可能存在精度損失的)。可是這個精度損失和 BigDecimal的構造函數 public BigDecimal(double val) 的精度損失相比而言，不會顯得那麼的突兀(也許咱們本身寫的doubleToBigDecimal也是存在問題的，歡迎指點)。

總結：

若是須要保證精度，最好是不要使用BigDecimal的double參數的構造函數，由於存在損失double參數精度的可能，最好是使用BigDecimal的String參數的構造函數。最好是杜絕使用BigDecimal的double參數的構造函數。

後記：

其實說這是BigDecimal的一個bug，有標題黨的嫌疑，最多能夠算做是BigDecimal的一個「坑」。

http://www.cnblogs.com/digdeep/p/4459781.html

噁心的0.5四捨五入問題

四捨五入是財務類應用中常見的需求，按中國人的財務習慣，遇到0.5統一貫上進位，可是c#與java中默認的卻不是這樣。

見c#代碼：

1         static void Main(string[] args) 2  { 3 Decimal d = 301353.05M; 4 Console.WriteLine(d);//301353.05 5 Console.WriteLine(Math.Round(d, 1));//301353.0 6 Console.WriteLine(Math.Round(d, 1, MidpointRounding.AwayFromZero));//301353.1 7 8  Console.ReadKey(); 9 }

默認狀況下，若是要捨棄的位置上，正好值是5，系統會看前一位是奇數仍是偶數，若是是偶數，則丟棄最後1位，即上面代碼行5，輸出的結果爲 301353.0，這不符合國人的習慣，因此要人爲指定第3個參數"MidpointRounding.AwayFromZero"

java中也提出了相似的作法，可是有「缺陷」

1  @Test 2 public void testScale(){ 3 double d = 301353.05; 4 BigDecimal decimal = new BigDecimal(d); 5 System.out.println(decimal);//301353.0499999999883584678173065185546875 6 System.out.println(decimal.setScale(1, RoundingMode.HALF_UP));//301353.0 7 }

相似的，在設置精度時，能夠指定一個額外的參數RoundingMode.HALF_UP，表示若是要捨棄的這一位正好是5，則向上進位，代碼看似沒有問題，可是輸出值倒是301353.0

緣由在於BigDecimal在計算機內部的存儲值爲"301353.0499999999883584678173065185546875"，即小數點第2位是4，上面的代碼要求精度到1位，因此代碼執行時，只看第2個小數位，其值爲4，沒有到HALF的標準，所以直接扔掉

改進方法：

1  @Test 2 public void testScale(){ 3 double d = 301353.05 + 0.0000000001; 4 BigDecimal decimal = new BigDecimal(d); 5 System.out.println(decimal);//301353.0500000001047737896442413330078125 6 System.out.println(decimal.setScale(1, RoundingMode.HALF_UP));//301353.1 7 }

在知足財務精度的前提下，將要處理的數字加1個微小的偏移量，這樣計算機內部存儲時，值變成301353.0500000001047737896442413330078125，這樣小數位第2位變成了5，知足了HALF_UP的條件。

http://www.cnblogs.com/yjmyzz/p/4427669.html

最根本的緣由是使用了錯誤的構造函數：BigDecimal decimal = new BigDecimal(d);致使了精度損失。使用下面的構造函數就不會致使精度損失了： BigDecimal decimal = new BigDecimal(String.valueOf(d)); 或者 BigDecimal decimal = new BigDecimal(new Double(d).toString()); 這是BigDecimal的一個坑。