抓住數據的小尾巴 - JS浮點數陷阱及解法
眾所周知,JavaScript 浮點數運算時經常遇到會 0.000000001
和 0.999999999
這樣奇怪的結果,如 0.1+0.2=0.30000000000000004
、1-0.9=0.09999999999999998
,很多人知道這是浮點數誤差問題,但具體原因就說不清楚了。本文幫你理清這背後的原理以及解決方案,還會向你解釋JS中的大數危機和四則運算中會遇到的坑。
浮點數的存儲
首先要搞清楚 JavaScript 如何存儲小數。和其它語言如 Java 和 Python 不同,JavaScript 中所有數字包括整數和小數都只有一種類型 — Number
。它的實現遵循 IEEE 754 標準,使用 64 位固定長度來表示,也就是標準的 double 雙精度浮點數(相關的還有float 32位單精度)。計算機組成原理中有過詳細介紹,如果你不記得也沒關係。
註:大多數語言中的小數默認都是遵循 IEEE 754 的 float 浮點數,包括 Java、Ruby、Python,本文中的浮點數問題同樣存在。
這樣的存儲結構優點是可以歸一化處理整數和小數,節省存儲空間。
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
。
最終的公式變成:
所以 4.5
最終表示為(M=001、E=1025):
(圖片由此生成 http://www.binaryconvert.com/convert_double.html)
下面再以 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 都轉化成二進位後再進行運算n0.00011001100110011001100110011001100110011001100110011010 +n0.0011001100110011001100110011001100110011001100110011010 =n0.0100110011001100110011001100110011001100110011001100111nn// 轉成十進位正好是 0.30000000000000004n
為什麼 x=0.1
能得到 0.1
?
恭喜你到了看山不是山的境界。因為 mantissa 固定長度是 52 位,再加上省略的一位,最多可以表示的數是 2^53=9007199254740992
,對應科學計數尾數是 9.007199254740992
,這也是 JS 最多能表示的精度。它的長度是 16,所以可以近似使用 toPrecision(16)
來做精度運算,超過的精度會自動做湊整處理。於是就有:
0.10000000000000000555.toPrecision(16)n// 返回 0.1000000000000000,去掉末尾的零後正好為 0.1nn// 但你看到的 `0.1` 實際上並不是 `0.1`。不信你可用更高的精度試試:n0.1.toPrecision(21) = 0.100000000000000005551n
大數危機
可能你已經隱約感覺到了,如果整數大於 9007199254740992 會出現什麼情況呢?
由於 E 最大值是 1023,所以最大可以表示的整數是2^1024 - 1
,這就是能表示的最大整數。但你並不能這樣計算這個數字,因為從 2^1024
開始就變成了 Infinity
> Math.pow(2, 1023)n8.98846567431158e+307nn> Math.pow(2, 1024)nInfinityn
那麼對於 (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 // Truen
封裝成方法就是:
function strip(num, precision = 12) {n return +parseFloat(num.toPrecision(precision));n}n
為什麼選擇 12
做為默認精度?這是一個經驗的選擇,一般選12就能解決掉大部分0001和0009問題,而且大部分情況下也夠用了,如果你需要更精確可以調高。
數據運算類
對於運算類操作,如 +-*/
,就不能使用 toPrecision
了。正確的做法是把小數轉成整數後再運算。以加法為例:
/**n * 精確加法n */nfunction add(num1, num2) {n const num1Digits = (num1.toString().split(.)[1] || ).length;n const num2Digits = (num2.toString().split(.)[1] || ).length;n const baseNum = Math.pow(10, Math.max(num1Digits, num2Digits));n return (num1 * baseNum + num2 * baseNum) / baseNum;n} n
以上方法能適用於大部分場景。遇到科學計數法如 2.3e+1
(當數字精度大於21時,數字會強制轉為科學計數法形式顯示)時還需要特別處理一下。
能讀到這裡,說明你非常有耐心,那我就放個福利吧。遇到浮點數誤差問題時可以直接使用
https://github.com/dt-fe/number-precision完美支持浮點數的加減乘除、四捨五入等運算。非常小只有1K,遠小於絕大多數同類庫(如Math.js、BigDecimal.js),100%測試全覆蓋,代碼可讀性強,不妨在你的應用里用起來!
參考
- Double-precision floating-point format
- What Every Programmer Should Know About Floating-Point Arithmetic
- Why Computers are Bad at Algebra | Infinite Series
- Is Your Model Susceptible to Floating-Point Errors?
如果你覺得本文對你有幫助,請猛擊喜歡鼓勵一下
推薦閱讀:
※數據分析的「去中心化」是大數據變現的必經之路!
※小白都能理解的數據分析和大數據(一)
※1.7號億級多CampaignPDB及移動ID講座【乾貨摘要】?
※Spark 2017歐洲技術峰會摘要(Engineering 分類)