抓住數據的小尾巴 - JS浮點數陷阱及解法

時間 2019-11-05

原文原文鏈接

原發於知乎專欄：zhuanlan.zhihu.com/ne-fehtml

衆所周知，JavaScript 浮點數運算時常常遇到會 0.000000001 和 0.999999999 這樣奇怪的結果，如 0.1+0.2=0.30000000000000004、1-0.9=0.09999999999999998，不少人知道這是浮點數偏差問題，但具體緣由就說不清楚了。本文幫你理清這背後的原理以及解決方案，還會向你解釋JS中的大數危機和四則運算中會遇到的坑。git

浮點數的存儲

首先要搞清楚 JavaScript 如何存儲小數。和其它語言如 Java 和 Python 不一樣，JavaScript 中全部數字包括整數和小數都只有一種類型 — Number。它的實現遵循 IEEE 754 標準，使用 64 位固定長度來表示，也就是標準的 double 雙精度浮點數（相關的還有float 32位單精度）。計算機組成原理中有過詳細介紹，若是你不記得也不要緊。github

注：大多數語言中的小數默認都是遵循 IEEE 754 的 float 浮點數，包括 Java、Ruby、Python，本文中的浮點數問題一樣存在。瀏覽器

這樣的存儲結構優勢是能夠歸一化處理整數和小數，節省存儲空間。bash

64位比特又可分爲三個部分：函數

符號位S：第 1 位是正負數符號位（sign），0表明正數，1表明負數
指數位E：中間的 11 位存儲指數（exponent），用來表示次方數
尾數位M：最後的 52 位是尾數（mantissa），超出的部分自動進一舍零

實際數字就能夠用如下公式來計算：性能

注意以上的公式遵循科學計數法的規範，在十進制中 0<M<10，到二進制就是 0<M<2。也就是說整數部分只能是1，因此能夠被捨去，只保留後面的小數部分。如 4.5 轉成二進制就是 100.1，科學計數法表示是 1.001*2^2，捨去1後 M = 001。E是一個無符號整數，由於長度是11位，取值範圍是 0~2047。可是科學計數法中的指數是能夠爲負數的，因此約定減去一箇中間數 1023，[0,1022] 表示爲負，[1024,2047] 表示爲正。如 4.5 的指數 E = 1025，尾數 M = 001。測試

最終的公式變成：ui

因此 4.5 最終表示爲（M=00一、E=1025）：spa

(圖片由今生成 www.binaryconvert.com/convert_dou…)

下面再以 0.1 爲例解釋浮點偏差的緣由，0.1 轉成二進制表示爲 0.0001100110011001100(1100循環)，1.100110011001100x2^-4，因此 E=-4+1023=1019；M 捨去首位的1，獲得 100110011...。最終就是：

轉化成十進制後爲 0.100000000000000005551115123126，所以就出現了浮點偏差。

爲何 `0.1+0.2=0.30000000000000004`？

計算步驟爲：

// 0.1 和 0.2 都轉化成二進制後再進行運算
0.00011001100110011001100110011001100110011001100110011010 +
0.0011001100110011001100110011001100110011001100110011010 =
0.0100110011001100110011001100110011001100110011001100111

// 轉成十進制正好是 0.30000000000000004複製代碼

爲何 `x=0.1` 能獲得 `0.1`？

恭喜你到了看山不是山的境界。由於 mantissa 固定長度是 52 位，再加上省略的一位，最多能夠表示的數是 2^53=9007199254740992，對應科學計數尾數是 9.007199254740992，這也是 JS 最多能表示的精度。它的長度是 16，因此能夠近似使用 toPrecision(16) 來作精度運算，超過的精度會自動作湊整處理。因而就有：

0.10000000000000000555.toPrecision(16)
// 返回 0.1000000000000000，去掉末尾的零後正好爲 0.1

// 但你看到的 `0.1` 實際上並非 `0.1`。不信你可用更高的精度試試：
0.1.toPrecision(21) = 0.100000000000000005551複製代碼

大數危機

可能你已經隱約感受到了，若是整數大於 9007199254740992 會出現什麼狀況呢？
因爲 E 最大值是 1023，因此最大能夠表示的整數是 2^1024 - 1，這就是能表示的最大整數。但你並不能這樣計算這個數字，由於從 2^1024 開始就變成了 Infinity

> Math.pow(2, 1023)
8.98846567431158e+307

> Math.pow(2, 1024)
Infinity複製代碼

那麼對於 (2^53, 2^63) 之間的數會出現什麼狀況呢？

(2^53, 2^54) 之間的數會兩個選一個，只能精確表示偶數
(2^54, 2^55) 之間的數會四個選一個，只能精確表示4個倍數
... 依次跳過更多2的倍數

下面這張圖能很好的表示 JavaScript 中浮點數和實數（Real Number）之間的對應關係。咱們經常使用的 (-2^53, 2^53) 只是最中間很是小的一部分，越往兩邊越稀疏越不精確。

在淘寶早期的訂單系統中把訂單號看成數字處理，後來隨意訂單號暴增，已經超過了
9007199254740992，最終的解法是把訂單號改爲字符串處理。

要想解決大數的問題你能夠引用第三方庫 bignumber.js，原理是把全部數字看成字符串，從新實現了計算邏輯，缺點是性能比原生的差不少，因此原生支持大數就頗有必要了。TC39 已經有一個 Stage 3 的提案 proposal bigint，大數問題有望完全解決。在瀏覽器正式支持前，可使用 Babel 7.0 來實現，它的內部是自動轉換成 big-integer 來計算，這樣能保持精度但運算效率會下降。

`toPrecision` vs `toFixed`

數據處理時，這兩個函數很容易混淆。它們的共同點是把數字轉成字符串供展現使用。注意在計算的中間過程不要使用，只用於最終結果。

不一樣點就須要注意一下：

toPrecision 是處理精度，精度是從左至右第一個不爲0的數開始數起。
toFixed 是小數點後指定位數取整，從小數點開始數起。

二者都能對多餘數字作湊整處理，也有些人用 toFixed 來作四捨五入，但必定要知道它是有 Bug 的。

如：1.005.toFixed(2) 返回的是 1.00 而不是 1.01。

緣由： 1.005 實際對應的數字是 1.00499999999999989，在四捨五入時所有被捨去！

解法：使用四捨五入函數 Math.round() 來處理。但 Math.round(1.005 * 100) / 100 仍是不行，由於 1.005 * 100 = 100.49999999999999。還須要把乘法和除法精度偏差都解決後再使用 Math.round。可使用後面介紹的 number-precision#round 方法來解決。

解決方案

回到最關心的問題：如何解決浮點偏差。首先，理論上用有限的空間來存儲無限的小數是不可能保證精確的，但咱們能夠處理一下獲得咱們指望的結果。

數據展現類

當你拿到 1.4000000000000001 這樣的數據要展現時，建議使用 toPrecision 湊整並 parseFloat 轉成數字後再顯示，以下：

parseFloat(1.4000000000000001.toPrecision(12)) === 1.4  // True複製代碼

封裝成方法就是：

function strip(num, precision = 12) {
  return +parseFloat(num.toPrecision(precision));
}複製代碼

爲何選擇 12 作爲默認精度？這是一個經驗的選擇，通常選12就能解決掉大部分0001和0009問題，並且大部分狀況下也夠用了，若是你須要更精確能夠調高。

數據運算類

對於運算類操做，如 +-*/，就不能使用 toPrecision 了。正確的作法是把小數轉成整數後再運算。以加法爲例：

/** * 精確加法 */
function add(num1, num2) {
  const num1Digits = (num1.toString().split('.')[1] || '').length;
  const num2Digits = (num2.toString().split('.')[1] || '').length;
  const baseNum = Math.pow(10, Math.max(num1Digits, num2Digits));
  return (num1 * baseNum + num2 * baseNum) / baseNum;
}複製代碼