Brief
一天有個朋友問我“JS中計算0.7 * 180怎么會等于125.99999999998,坑也太多了吧!”那時我猜測是二進制表示數值時發生round-off error所導致,但并不清楚具體是如何導致,并且有什么方法去規避。于是用了3周時間靜下心把這個問題搞懂,在學習的過程中還發現不僅0.7 * 180==125.99999999998,還有以下的坑
1. 著名的 0.1 + 0.2 === 0.30000000000000004
2. 1000000000000000128
=== 1000000000000000129
IEEE 754 Floating-point
眾所周知JS僅有Number這個數值類型,而Number采用的時IEEE 754 64位雙精度浮點數編碼。而浮點數表示方式具有以下特點:
1. 浮點數可表示的值范圍比同等位數的整數表示方式的值范圍要大得多;
2. 浮點數無法精確表示其值范圍內的所有數值,而有符號和無符號整數則是精確表示其值范圍內的每個數值;
3. 浮點數只能精確表示m*2e的數值;
4. 當biased-exponent為2e-1-1時,浮點數能精確表示該范圍內的各整數值;
5. 當biased-exponent不為2e-1-1時,浮點數不能精確表示該范圍內的各整數值。
由于部分數值無法精確表示(存儲),于是在運算統計后偏差會愈見明顯。
想了解更多浮點數的知識可參考以下文章:
基礎野:細說原碼、反碼和補碼(http://www.cnblogs.com/fsjohnhuang/p/5060242.html)
基礎野:細說無符號整數(http://www.cnblogs.com/fsjohnhuang/p/5078290.html)
基礎野:細說有符號整數(http://www.cnblogs.com/fsjohnhuang/p/5082829.html)
基礎野:細說浮點數(http://www.cnblogs.com/fsjohnhuang/p/5109766.html)
Why 0.1 + 0.2 === 0.30000000000000004 ?
在浮點數運算中產生誤差值的示例中,最出名應該是0.1 + 0.2 === 0.30000000000000004了,到底有多有名?看看這個網站就知道了http://0.30000000000000004.com/。也就是說不僅是JavaScript會產生這種問題,只要是采用IEEE 754 Floating-point的浮點數編碼方式來表示浮點數時,則會產生這類問題。下面我們來分析整個運算過程。
1. 0.1 的二進制表示為 1.1001100110011001100110011001100110011001100110011001 1(0011)+ * 2^-4;
2. 當64bit的存儲空間無法存儲完整的無限循環小數,而IEEE 754 Floating-point采用round to nearest, tie to even的舍入模式,因此0.1實際存儲時的位模式是0-01111111011-1001100110011001100110011001100110011001100110011010;
3. 0.2 的二進制表示為 1.1001100110011001100110011001100110011001100110011001 1(0011)+ * 2^-3;
4. 當64bit的存儲空間無法存儲完整的無限循環小數,而IEEE 754 Floating-point采用round to nearest, tie to even的舍入模式,因此0.2實際存儲時的位模式是0-01111111100-1001100110011001100110011001100110011001100110011010;
5. 實際存儲的位模式作為操作數進行浮點數加法,得到 0-01111111101-0011001100110011001100110011001100110011001100110100。轉換為十進制即為0.30000000000000004。
Why 0.7 * 180===125.99999999998 ?
1. 0.7實際存儲時的位模式是0-01111111110-0110011001100110011001100110011001100110011001100110;
2. 180實際存儲時的位模式是0-10000000110-0110100000000000000000000000000000000000000000000000;
3. 實際存儲的位模式作為操作數進行浮點數乘法,得到0-10000000101-1111011111111111111111111111111111111111101010000001。轉換為十進制即為125.99999999998。
Why 1000000000000000128
=== 1000000000000000129
?
1. 1000000000000000128
實際存儲時的位模式是0-10000111010-1011110000010110110101100111010011101100100000000001;
2. 1000000000000000129
實際存儲時的位模式是0-10000111010-1011110000010110110101100111010011101100100000000001;
3. 因此1000000000000000128和
1000000000000000129的實際存儲的位模式是一樣的。
Solution
到這里我們都理解只要采取IEEE 754 FP的浮點數編碼的語言均會出現上述問題,只是它們的標準類庫已經為我們提供了解決方案而已。而JS呢?顯然沒有。壞處自然是掉坑了,而好處恰恰也是掉坑了:)
針對不同的應用需求,我們有不同的實現方式。
Solution 0x00 - Simple implementation
對于小數和小整數的簡單運算可用如下方式
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; };
Solution 0x01 - math.js
若需要復雜且全面的運算功能那必須上math.js,其內部引用了decimal.js和fraction.js。功能異常強大,用于生產環境上妥妥的!
Solution 0x02 - D.js
D.js算是我的練手項目吧,截止本文發表時D.js版本為V0.2.0,僅實現了加、減、乘和整除運算而已,bug是一堆堆的,但至少解決了0.1+0.2的問題了。
var sum = D.add(0.1, 0.2) console.log(sum + '') // 0.3 var product = D.mul("1e-2", "2e-4") console.log(product + '') // 0.000002 var quotient = D.div(-3, 2) console.log(quotient + '') // -(1+1/2)
解題思路:
1. 由于僅位于Number.MIN_SAFE_INTEGER和Number.MAX_SAFE_INTEGER間的整數才能被精準地表示,也就是只要保證運算過程的操作數和結果均落在這個閥值內,那么運算結果就是精準無誤的;
2. 問題的關鍵落在如何將小數和極大數轉換或拆分為Number.MIN_SAFE_INTEGER至Number.MAX_SAFE_INTEGER閥值間的數了;
3. 小數轉換為整數,自然就是通過科學計數法表示,并通過右移小數點,減小冪的方式處理;(如0.000123 等價于 123 * 10-6)
4. 而極大數則需要拆分,拆分的規則是多樣的。
4.1. 按因式拆分:假設對12345進行拆分得到 5 * 2469;
4.2. 按位拆分:假設以3個數值為一組對12345進行拆分得到345和12,而實際值為12*1000 + 345。
就我而言,4.1的拆分規則結構不穩定,而且不直觀;而4.2的規則直觀,且拆分和恢復的公式固定。
5. 余數由符號位、分子和分母組成,而符號與整數部分一致,因此只需考慮如何表示分子和分母即可。
6. 無限循環數則僅需考慮如何表示循環數段即可。(如10.2343434則分成10.23 和循環數34和34的權重即可)
得到編碼規則后,那就剩下基于指定編碼如何實現各種運算的問題了。
1. 基于上述的數值編碼規則如何實現加、減運算呢?
2. 基于上述的數值編碼規則如何實現乘、除運算呢?(其實只要加、減運算解決了,乘除必然可解,就是效率問題而已)
3. 基于上述的數值編碼規則如何實現其它如sin、tan、%等數學運算呢?
另外由于涉及數學運算,那么將作為add、sub、mul和div等入參的變量保持如同數學公式運算數般純凈(Persistent/Immutable Data Structure)是必須的,那是否還要引入immutable.js呢?(D.js現在采用按需生成副本的方式,可預見隨著代碼量的增加,這種方式會導致整體代碼無法維護)
Conclusion
依照我的尿性,D.js將采取不定期持續更新的策略(待我理解Persistent/Immutable Data Structure后吧:))。歡迎各位指教!
尊重原創,轉載請注明來自:http://www.cnblogs.com/fsjohnhuang/p/5115672.html^_^肥子John
Thanks
http://es5.github.io
https://github.com/MikeMcl/decimal.js/
http://www.ruanyifeng.com/blog/2010/06/ieee_floating-point_representation.html
http://demon.tw/copy-paste/javascript-precision.html
文章列表