該死的IEEE-754浮點數，說「約」就「約」，你的底線呢？以JS的名義來好好查查你

時間  2019-11-12
標籤 該死 ieee 浮點數 底線 名義 好好 查查 欄目 JavaScript 简体版
原文   原文鏈接

IEEE 754 表示：你儘管抓狂、罵娘，但你能徹底避開我，算我輸。javascript

1、IEEE-754浮點數捅出的那些婁子

首先咱們仍是來看幾個簡單的問題，能說出每個問題的細節的話就能夠跳過了，而若是隻能泛泛說一句「由於IEEE754浮點數精度問題」，那麼下文仍是值得一看。html

第一個問題是知名的0.1+0.2 != 0.3，爲何？菜鳥會告訴你「由於IEEE 754的浮點數表示標準」，老鳥會補充道「0.1和0.2不能被二進制浮點數精確表示，這個加法會使精度喪失」，巨鳥會告訴你整個過程是怎樣的，小數加法精度可能在哪幾步喪失，你能答上細節麼？前端

第二個問題，既然十進制0.1不能被二進制浮點數精確存儲，那麼爲何console.log(0.1)打印出來的確確實實是0.1這個精確的值？java

第三個問題，你知道這些比較結果是怎麼回事麼？程序員

//這相等和不等是怎麼回事？
0.100000000000000002 ==
0.100000000000000010 // true

0.100000000000000002 ==
0.100000000000000020 // false

//顯然下面的數值沒有超過Number.MAX_SAFE_INTEGER的範圍，爲何是這樣？
Math.pow(10, 10) + Math.pow(10, -7) === Math.pow(10, 10) //  true
Math.pow(10, 10) + Math.pow(10, -6) === Math.pow(10, 10) //  false

追問一句，給出一個數，給這個數加一個增量，再和這個數比較，要保持結果是true，即相等，那麼大約這個增量的數量級最大能夠到多少，你能估計出來麼？segmentfault

第四個問題，旁友，你知道下面這段一直在被引用的的代碼麼（這段代碼用於解決常見範圍內的小數加法以符合常識，好比將0.1+0.2結果精確計算爲0.3）？你理解這樣作的思路麼？可是你知道這段代碼有問題麼？好比你計算268.34+0.83就會出現問題。安全

//注意函數接受兩個string形式的數
function numAdd(num1/*:String*/, num2/*:String*/) { 
    var baseNum, baseNum1, baseNum2; 
    try { 
        baseNum1 = num1.split(".")[1].length; 
    } catch (e) { 
        baseNum1 = 0; 
    } 
    try { 
        baseNum2 = num2.split(".")[1].length; 
    } catch (e) { 
        baseNum2 = 0;
    } 
    baseNum = Math.pow(10, Math.max(baseNum1, baseNum2)); 
    return (num1 * baseNum + num2 * baseNum) / baseNum; 
};

//看上去好像解決了0.1+0.2
numAdd("0.1","0.2"); //返回精確的0.3

//可是你試試這個
numAdd("268.34","0.83");//返回 269.16999999999996

那麼多問題，還真是該死的IEEE-754，而這一切都源於IEEE-754浮點數自己的格式，以及「說「約」就「約」」（舍入）的規則，導致精度喪失，計算淪喪，做爲一個前端，咱們就從JS的角度來扒一扒。wordpress

2、端詳一下IEEE-754雙精度浮點的樣貌

所謂「知己知彼，百戰不殆」，要從內部瓦解敵人，就要先了解敵人，但爲何只選擇雙精度呢，由於知道了雙精度就明白了單精度，並且在JavaScript中，全部的Number都是以64-bit的雙精度浮點數存儲的，因此咱們來回顧一下究竟是怎麼存儲的，以及這樣子存儲怎麼映射到具體的數值。函數

IEEE754浮點數形式

二進制在存儲的時候是以二進制的「科學計數法」來存儲的，咱們回顧下十進制的科學計數法，好比54846.3，這個數咱們在用標準的科學計數法應該是這樣的：5.48463e4，這裏有三部分，第一是符號，這是一個正數，只是通常省略正號不寫，第二是有效數字部分，這裏就是5.48463，最後是指數部分，這裏是4。以上就是在十進制領域下的科學計數法，換到二進制也是同樣，只是十進制下以10爲底，二進制以2爲底。工具

雙精度的浮點數在這64位上劃分爲3段，而這3段也就肯定了一個浮點數的值，64bit的劃分是「1-11-52」的模式，具體來講：

  • 就是1位最高位（最左邊那一位）表示符號位，0表示正，1表示負
  • 接下去11位表示指數部分
  • 最後52位表示尾數部分，也就是有效域部分

這裏幺蛾子就不少了。首先「每一個實數都有一個相反數」這是中學教的，因而符號位改變下就是一個相反數了，可是對於數字0來講，相反數就是本身，而符號位對於每個由指數域和尾數域肯定的數都是一視同仁，有正就有負，要麼都沒有。因此這裏就有正0和負0的概念，可是正0和負0是相等的，可是他們能反應出符號位的不一樣，和正零、負零相關的有意思的事這裏不贅述。

而後，指數不必定要正數吧，能夠是負數吧，一種方式是指數域部分也設置一個符號位，第二種是IEEE754採起的方式，設置一個偏移，使指數部分永遠表現爲一個非負數，而後減去某個偏移值纔是真實的指數，這樣作的好處是能夠表現一些極端值，咱們等會會看到。而64bit的浮點數設置的偏移值是1023，由於指數域表現爲一個非負數，11位，因此 0 <= e <= 2^11 -1，實際的E=e-1023，因此 -1023 <= E <= 1024。這兩端的兩個極端值結合不一樣的尾數部分表明了不一樣的含義。

最後，尾數部分，也就是有效域部分，爲何叫有效域部分，舉個栗子，這裏有52個坑，可是你的數字由60個二進制1組成，無論怎樣，你都是不能徹底放下的，只能放下52個1，那剩下的8個1呢？要麼舍入要麼捨棄了，總之是無效了。因此，尾數部分決定了這個數的精度。

而對於二進制的科學計數法，若是保持小數點前必須有一位非0的，那有效域是否是必然是1.XXXX的形式？而這樣子的二進制被稱爲規格化的，這樣的二進制在存儲時，小數點前的1是默認存在，可是默認不佔坑的，尾數部分就存儲小數點後的部分。

問題來了，若是這個二進制小數過小了，那麼會出現什麼狀況呢？對於一個接近於0的二進制小數，一味追求1.xxx的形式，必然致使指數部分會向負無窮靠攏，而真實的指數部分最小也就能表示-1023，一旦把指數部分逼到了-1023，尚未到1.xxx的形式，那麼只能用0.xxx的形式表示有效部分，這樣的二進制浮點數表示非規格化的。

因而，咱們整一個64位浮點數能表示的值由符號位s，指數域e和尾數域f肯定以下，從中咱們能夠看到正負零、規格化和非規格化二進制浮點數、正負無窮是怎麼表示的：

浮點數形式和數值的映射

這裏的(0.f)和(1.f)指的是二進制的表示，都要轉化爲十進制再去計算，這樣你就能夠獲得最終值。

回顧了IEEE754的64bit浮點數以後，有如下3點須要牢記的：

  1. 指數和尾數域是有限的，一個是11位，一個是52位
  2. 符號位決定正負，指數域決定數量級，尾數域決定精度
  3. 全部數值的計算和比較，都是這樣以64個bit的形式來進行的，拋開腦海中想固然的十進制

3、精度在哪裏發生丟失

當你直接計算0.1+0.2時，你要知道「你大媽已經不是你大媽，你大爺也已經不是你大爺了，因此他們生的孩子（結果）出現問題就能夠理解了」。這裏的0.1和0.2是十進制下的0.1和0.2，當它們轉化爲二進制時，它們是無限循環的二進制表示。

這引出第一處可能丟失精度的地方，即在十進制轉二進制的過程當中丟失精度。由於大部分的十進制小數是不能被這52位尾數的二進制小數表示完畢的，咱們眼中最簡單的0.一、0.2在轉化爲二進制小數時都是無限循環的，還有些可能不是無限循環的，可是轉化爲二進制小數的時候，小數部分超過了52位，那也是放不下的。

那麼既然只有52位的有效域，那麼必然超出52位的部分會發生一件靈異事件——閹割，文明點叫「舍入」。IEEE754規定了幾種舍入規則，可是默認的是舍入到最接近的值，若是「舍」和「入」同樣接近，那麼取結果爲偶數的選擇。

因此上面的0.1+0.2中，當0.1和0.2被存儲時，存進去的已經不是精確的0.1和0.2了，而是精度發生必定丟失的值。可是精度丟失尚未完，當這個兩個值發生相加時，精度還可能進一步丟失，注意幾回精度丟失的疊加不必定使結果誤差愈來愈大哦。

第二處可能丟失精度的地方是浮點數參與計算時，浮點數參與計算時，有一個步驟叫對階，以加法爲例，要把小的指數域轉化爲大的指數域，也就是左移小指數浮點數的小數點，一旦小數點左移，必然會把52位有效域的最右邊的位給擠出去，這個時候擠出去的部分也會發生「舍入」。這就又會發生一次精度丟失。

因此就0.1+0.2這個例子精度在兩個數轉爲二進制過程當中和相加過程當中都已經丟失了精度，那麼最後的結果有問題，不能如願也就不奇怪了，若是你很想探究具體這是怎麼計算的，文末附錄的連接能幫助你。

4、疑惑：0.1不能被精確表示，但打印0.1它就是0.1啊

是的，照理說，0.1不能被精確表示，存儲的是0.1的一個近似值，那麼我打印0.1時，好比console.log(0.1)，就是打印出了精確的0.1啊。

事實是，當你打印的時候，其實發生了二進制轉爲十進制，十進制轉爲字符串，最後輸出的。而十進制轉爲二進制會發生近似，那麼二進制轉爲十進制也會發生近似，打印出來的值實際上是近似過的值，並非對浮點數存儲內容的精確反映。

關於這個問題，StackOverflow上有一個回答能夠參考，回答中指出了一篇文獻，有興趣的能夠去看：

How does javascript print 0.1 with such accuracy?

5、相等不相等，就看這64個bit

再次強調，全部數值的計算和比較，都是這樣以64個bit的形式來進行的，當這64個bit容不下時，就會發生近似，一近似就發生意外了。

有一些在線的小數轉IEEE754浮點數的應用對於驗證一些結果仍是頗有幫助的，你能夠用這個IEEE-754 Floating-Point Conversion工具幫你驗證你的小數轉化爲IEEE754浮點數以後是怎麼個鬼樣。

來看第一部分中提出兩個簡單的比較問題：

//這相等和不等是怎麼回事？
0.100000000000000002 ==
0.1  //true

0.100000000000000002 ==
0.100000000000000010 // true

0.100000000000000002 ==
0.100000000000000020 // false

當你把0.1、0.100000000000000002、0.10000000000000001和0.10000000000000002用上面的工具轉爲浮點數後，你會發現，他們的尾數部分（注意看尾數部分最低4位，其他位都是相同的），前三個是相同的，最低4位是1010，可是最後一個轉化爲浮點數尾數最低4位是1011。

這是由於它們在轉爲二進制時要舍入部分的不一樣可能形成的不一樣舍入致使在尾數上可能呈現不一致，而比較兩個數，本質上是比較這兩個數的這64個bit，不一樣便是不等的，有一個例外，+0==-0。

再來看提到的第二個相等問題：

Math.pow(10, 10) + Math.pow(10, -7) === Math.pow(10, 10) //  true
Math.pow(10, 10) + Math.pow(10, -6) === Math.pow(10, 10) //  false

爲何上面一個是能夠相等的，下面一個就不行了，首先咱們來轉化下：

Math.pow(10, 10) =>
指數域 e =1056 ，即 E = 33
尾數域 (1.)0010101000000101111100100000000000000000000000000000

Math.pow(10, -7) =>
指數域 e =999 ，即 E = -24

Math.pow(10, -6) =>
指數域 e =1003 ，即 E = -20
尾數域 (1.)0000110001101111011110100000101101011110110110001101

能夠看到1e10的指數是33次，而Math.pow(10, -7)指數是-24次，相差57次，遠大於52，所以，相加時發生對階，早就把Math.pow(10, -7)近似成0了。

而Math.pow(10, -6)指數是-20次，相差53次，看上去大於52次，但有一個默認的前導1別忘了，因而當發生對階，小數點左移53位時，這一串尾數（別忘了前導1）正好被擠出第52位，這時候就會發生」舍入「，舍入結果是最低位，也就是bit0位變成1，這個時候和Math.pow(10, 10)相加，結果的最低位變成了1，天然和Math.pow(10, 10)不相等。

你能夠用這個IEEE754計算器來驗證結果。

6、淺析數值和數值精度的數量級對應關係

承接上面的那個結果，咱們發現當數值爲10的10次時，加一個-7數量級的數，對於值沒有影響，加一個-6數量級的數，卻對值由影響，這裏的本質咱們也是知道的：

這是因爲計算時要對階，若是一個小的增量在對階時最高有效位右移（由於小數點在左移）到了52位開外，那麼這個增量就極可能被忽略，即對階完尾數被近似成0。

換句話說，咱們能夠說對於10<sup>10</sup>數量級，其精確度大約在10<sup>-6</sup>數量級，那麼對於10<sup>9</sup>、10<sup>8</sup>、10<sup>0</sup>等等數量級的值，精確度又大約在多少呢？

有一張圖很好地說明了這個對應關係：

數值數量級和精確度數量級對應關係

這張圖，橫座標表示浮點數值數量級，縱座標表示能夠到達的精度的數量級，固然這裏橫座標對應的數值數量級指的是十進制表示下的數量級。

好比你在控制檯測試（.toFixed()函數接受一個20及之內的整數n以顯示小數點後n位）：

0.1.toFixed(20) ==> 0.10000000000000000555（這裏也能夠看出0.1是精確存儲的），根據上面的圖咱們知道0.1是10<sup>-1</sup>數量級的，那麼精確度大約在10<sup>-17</sup>左右，而咱們驗證一下:

//動10的-18數量級及以後的數字，並不會有什麼，依舊斷定相等
0.10000000000000000555 ==
0.10000000000000000999  //true
//動10的-17數量級上的數字，結果立刻不同了
0.10000000000000000555 ==
0.10000000000000001555  //false

從圖上也能夠看到以前的那個例子，10<sup>10</sup>數量級，精確度在10<sup>-6</sup>數量級。

也就是說，在IEEE754的64位浮點數表示下，若是一個數的數量級在10<sup>X</sup>，其精確度在10<sup>Y</sup>，那麼X和Y大體知足：

X-16=Y

知道這個以後咱們再回過頭來看ECMA在定義的Number.EPSILON，若是還不知道有這個的存在，能夠控制檯去輸出下，這個數大約是10<sup>-16</sup>數量級的一個數，這個數定義爲」大於1的能用IEEE754浮點數表示爲數值的最小數與1的差值「，這個數用來幹嗎呢？

0.1+0.2-0.3<Number.EPSILON是返回true的，也就是說ECMA預設了一個精度，便於開發者使用，可是咱們如今能夠知道這個預約義的值實際上是對應 10<sup>0</sup> 數量級數值的精確度，若是你要比較更小數量級的兩個數，預約義的這個Number.EPSILON就不夠用了（不夠精確了），你能夠用數學方式將這個預約義值的數量級進行縮小。

7、麻煩稍小的整數提供一種解決思路

那麼怎樣能在計算機中實現看上去比較正常和天然的小數計算呢？好比0.1+0.2就輸出0.3。其中一個思路，也是目前足夠應付大多數場景的思路就是，將小數轉化爲整數，在整數範圍內計算結果，再把結果轉化爲小數，由於存在一個範圍，這個範圍內的整數是能夠被IEEE754浮點形式精確表示的，換句話說這個範圍內的整數運算，結果都是精確的，而大部分場景下這個數的範圍已經夠用，因此這種思路可行。

1. JS中數的「量程」和「精度」

之因此說一個範圍，而不是全部的整數，是由於整數也存在精確度的問題，要深入地理解，」可表示範圍「和」精確度「兩個概念的區別，就像一把尺子的」量程「和」精度「。

JS所能表示的數的範圍，以及能表示的安全整數範圍（安全是指不損失精確度）由如下幾個值界定：

//本身能夠控制檯打印看看
Number.MAX_VALUE => 能表示的最大正數，數量級在10的308次
Number.MIN_VALUE => 能表示的最小正數，注意不是最小數，最小數是上面那個取反，10的-324數量級

Number.MAX_SAFE_INTEGER => 能表示的最大安全數，9開頭的16位數
Number.MIN_SAFE_INTEGER => 能表示的最小安全數，上面那個的相反數

爲何超過最大安全數的整數都不精確了呢？仍是回到IEEE754的那幾個坑上，尾數就52個坑，有效數再多，就要發生舍入了。

2. 一段有瑕疵的解決浮點計算異常問題的代碼

所以，回到解決JS浮點數的精確計算上來，能夠把待計算的小數轉化爲整數，在安全整數範圍內，再計算結果，再轉回小數。

因此有了下面這段代碼（但這是有問題的）：

//注意要傳入兩個小數的字符串表示，否則在小數轉成二進制浮點數的過程當中精度就已經損失了
function numAdd(num1/*:String*/, num2/*:String*/) { 
    var baseNum, baseNum1, baseNum2; 
    try { 
        //取得第一個操做數小數點後有幾位數字，注意這裏的num1是字符串形式的
        baseNum1 = num1.split(".")[1].length; 
    } catch (e) {
        //沒有小數點就設爲0 
        baseNum1 = 0; 
    } 
    try { 
        //取得第二個操做數小數點後有幾位數字
        baseNum2 = num2.split(".")[1].length; 
    } catch (e) { 
        baseNum2 = 0;
    }
    //計算須要 乘上多少數量級 才能把小數轉化爲整數 
    baseNum = Math.pow(10, Math.max(baseNum1, baseNum2)); 
    //把兩個操做數先乘上計算所得數量級轉化爲整數再計算，結果再除以這個數量級轉回小數
    return (num1 * baseNum + num2 * baseNum) / baseNum; 
};

思路沒有問題，看上去也解決了0.1+0.2的問題，用上面的函數計算numAdd("0.1","0.2")時，輸出確實是0.3。可是再多試幾個，好比numAdd("268.34","0.83")，輸出是269.16999999999996，瞬間爆炸，這些代碼一行都不想再看。

其實仔細分析一下，這個問題仍是很好解決的。問題是這麼發生的，有一個隱式的類型轉換，上面的num1和num2傳入都是字符串類型的，可是在最後return的那個表達式中，直接參與計算，因而num1和num2隱式地從String轉爲Number，而Number是以IEEE754浮點數形式儲存的，在十進制轉爲二進制過程當中，精度會損失。

咱們能夠在上面代碼的return語句之上加上這兩句看看輸出是什麼：

console.log(num1 * baseNum);
console.log(num2 * baseNum);

你會發現針對numAdd("268.34","0.83")的例子，上面兩行輸出26833.999999999996、83。能夠看到轉化爲整數的夢想並無被很好地實現

要解決這個問題也很容易，就是咱們顯式地讓小數「乖乖」轉爲整數，由於咱們知道兩個操做數乘上計算所得數量級必然應該是一個整數，只是因爲精度損失放大致使被近似成了一個小數，那咱們把結果保留到整數部分不就能夠了麼？

也就是把上面最後一句的

return (num1 * baseNum + num2 * baseNum) / baseNum; 改成 return (num1 * baseNum + num2 * baseNum).toFixed(0) / baseNum;

分子上的.toFixed(0)表示精確到整數位，這基於咱們明確地知道分子是一個整數。

3. 侷限性和其餘可能的思路

這種方式的侷限性在於我要乘上一個數量級把小數轉爲整數，若是小數部分很長呢，那麼經過這個方式轉化出的整數就超過了安全整數的範圍，那麼計算也就不安全了。

不過仍是一句話，看使用場景進行選擇，若是侷限性不會出現或者出現了可是無傷大雅，那就能夠應用。

另外一種思路是將小數轉爲字符串，用字符串去模擬，這樣子作可適用的範圍比較廣，可是實現過程會比較繁瑣。

若是你的項目中須要屢次面臨這樣的計算，又不想本身實現，那麼也有現成的庫可使用，好比math.js，感謝這個美好的世界吧。

8、小結

做爲一個JS程序員，IEEE754浮點數可能不會常常讓你心煩，可是明白這些能讓你在之後遇到相關意外時保持冷靜，正常看待。看徹底文，咱們應該能明白IEEE754的64位浮點數表示方式和對應的值，能明白精度和範圍的區別，能明白精度損失、意外的比較結果都是源自於那有限數量的bit，而不用每次遇到相似問題就發一個日經的問題，不會就知道「IEEE754」這一個詞的皮毛卻說不出一句完整的表達，最重要是可以心平氣和地罵一句「你這該死的IEEE754」後繼續coding...

若有紕漏煩請留言指出，謝謝。

附：感謝如下內容對個人幫助

實現js浮點數加、減、乘、除的精確計算
IEEE-754 Floating-Point Conversion IEEE-754浮點數轉換工具
IEEE754 浮點數格式 與 Javascript number 的特性
Number.EPSILON及其它屬性

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程