摘要：也就是說不僅是會產(chǎn)生這種問題，只要是采用的浮點數(shù)編碼方式來表示浮點數(shù)時，則會產(chǎn)生這類問題。到這里我們都理解只要采取的浮點數(shù)編碼的語言均會出現(xiàn)上述問題，只是它們的標(biāo)準(zhǔn)類庫已經(jīng)為我們提供了解決方案而已。

一天有個朋友問我“JS中計算0.7 * 180怎么會等于125.99999999998，坑也太多了吧！”那時我猜測是二進制表示數(shù)值時發(fā)生round-off error所導(dǎo)致，但并不清楚具體是如何導(dǎo)致，并且有什么方法去規(guī)避。于是用了3周時間靜下心把這個問題搞懂，在學(xué)習(xí)的過程中還發(fā)現(xiàn)不僅0.7 * 180==125.99999999998，還有以下的坑

著名的 0.1 + 0.2 === 0.30000000000000004

1000000000000000128 === 1000000000000000129

眾所周知JS僅有Number這個數(shù)值類型，而Number采用的時IEEE 754 64位雙精度浮點數(shù)編碼。而浮點數(shù)表示方式具有以下特點：

浮點數(shù)可表示的值范圍比同等位數(shù)的整數(shù)表示方式的值范圍要大得多；

浮點數(shù)無法精確表示其值范圍內(nèi)的所有數(shù)值，而有符號和無符號整數(shù)則是精確表示其值范圍內(nèi)的每個數(shù)值；

浮點數(shù)只能精確表示m*2e的數(shù)值；

當(dāng)biased-exponent為2e-1-1時，浮點數(shù)能精確表示該范圍內(nèi)的各整數(shù)值；

當(dāng)biased-exponent不為2e-1-1時，浮點數(shù)不能精確表示該范圍內(nèi)的各整數(shù)值。

由于部分?jǐn)?shù)值無法精確表示（存儲），于是在運算統(tǒng)計后偏差會愈見明顯。

想了解更多浮點數(shù)的知識可參考以下文章：

《基礎(chǔ)野：細說原碼、反碼和補碼》

《基礎(chǔ)野：細說無符號整數(shù)》

《基礎(chǔ)野：細說有符號整數(shù)》

《基礎(chǔ)野：細說浮點數(shù)》

在浮點數(shù)運算中產(chǎn)生誤差值的示例中，最出名應(yīng)該是0.1 + 0.2 === 0.30000000000000004了，到底有多有名？看看這個網(wǎng)站就知道了http://0.30000000000000004.com/。也就是說不僅是JavaScript會產(chǎn)生這種問題，只要是采用IEEE 754 Floating-point的浮點數(shù)編碼方式來表示浮點數(shù)時，則會產(chǎn)生這類問題。下面我們來分析整個運算過程。

0.1 的二進制表示為 1.1001100110011001100110011001100110011001100110011001 1(0011)+ * 2^-4；

當(dāng)64bit的存儲空間無法存儲完整的無限循環(huán)小數(shù)，而IEEE 754 Floating-point采用round to nearest, tie to even的舍入模式，因此0.1實際存儲時的位模式是0-01111111011-1001100110011001100110011001100110011001100110011010；

0.2 的二進制表示為 1.1001100110011001100110011001100110011001100110011001 1(0011)+ * 2^-3；

當(dāng)64bit的存儲空間無法存儲完整的無限循環(huán)小數(shù)，而IEEE 754 Floating-point采用round to nearest, tie to even的舍入模式，因此0.2實際存儲時的位模式是0-01111111100-1001100110011001100110011001100110011001100110011010；

實際存儲的位模式作為操作數(shù)進行浮點數(shù)加法，得到 0-01111111101-0011001100110011001100110011001100110011001100110100。轉(zhuǎn)換為十進制即為0.30000000000000004。

0.7實際存儲時的位模式是0-01111111110-0110011001100110011001100110011001100110011001100110；

180實際存儲時的位模式是0-10000000110-0110100000000000000000000000000000000000000000000000；

實際存儲的位模式作為操作數(shù)進行浮點數(shù)乘法，得到0-10000000101-1111011111111111111111111111111111111111101010000001。轉(zhuǎn)換為十進制即為125.99999999998。

1000000000000000128實際存儲時的位模式是0-10000111010-1011110000010110110101100111010011101100100000000001；

1000000000000000129實際存儲時的位模式是0-10000111010-1011110000010110110101100111010011101100100000000001；

因此1000000000000000128和1000000000000000129的實際存儲的位模式是一樣的。

到這里我們都理解只要采取IEEE 754 FP的浮點數(shù)編碼的語言均會出現(xiàn)上述問題，只是它們的標(biāo)準(zhǔn)類庫已經(jīng)為我們提供了解決方案而已。而JS呢？顯然沒有。壞處自然是掉坑了，而好處恰恰也是掉坑了:)

針對不同的應(yīng)用需求，我們有不同的實現(xiàn)方式。

對于小數(shù)和小整數(shù)的簡單運算可用如下方式

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; 
};

若需要復(fù)雜且全面的運算功能那必須上math.js，其內(nèi)部引用了decimal.js和fraction.js。功能異常強大，用于生產(chǎn)環(huán)境上妥妥的！

D.js算是我的練手項目吧，截止本文發(fā)表時D.js版本為V0.2.0，僅實現(xiàn)了加、減、乘和整除運算而已，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)

解題思路：

由于僅位于Number.MIN_SAFE_INTEGER和Number.MAX_SAFE_INTEGER間的整數(shù)才能被精準(zhǔn)地表示，也就是只要保證運算過程的操作數(shù)和結(jié)果均落在這個閥值內(nèi)，那么運算結(jié)果就是精準(zhǔn)無誤的；

問題的關(guān)鍵落在如何將小數(shù)和極大數(shù)轉(zhuǎn)換或拆分為Number.MIN_SAFE_INTEGER至Number.MAX_SAFE_INTEGER閥值間的數(shù)了；

小數(shù)轉(zhuǎn)換為整數(shù)，自然就是通過科學(xué)計數(shù)法表示，并通過右移小數(shù)點，減小冪的方式處理；(如0.000123 等價于 123 * 10-6)

而極大數(shù)則需要拆分，拆分的規(guī)則是多樣的。

按因式拆分：假設(shè)對12345進行拆分得到 5 * 2469；

按位拆分：假設(shè)以3個數(shù)值為一組對12345進行拆分得到345和12，而實際值為12*1000 + 345。
就我而言，1 的拆分規(guī)則結(jié)構(gòu)不穩(wěn)定，而且不直觀；而 2 的規(guī)則直觀，且拆分和恢復(fù)的公式固定。

余數(shù)由符號位、分子和分母組成，而符號與整數(shù)部分一致，因此只需考慮如何表示分子和分母即可。

無限循環(huán)數(shù)則僅需考慮如何表示循環(huán)數(shù)段即可。（如10.2343434則分成10.23 和循環(huán)數(shù)34和34的權(quán)重即可）

得到編碼規(guī)則后，那就剩下基于指定編碼如何實現(xiàn)各種運算的問題了。

基于上述的數(shù)值編碼規(guī)則如何實現(xiàn)加、減運算呢？

基于上述的數(shù)值編碼規(guī)則如何實現(xiàn)乘、除運算呢？（其實只要加、減運算解決了，乘除必然可解，就是效率問題而已）

基于上述的數(shù)值編碼規(guī)則如何實現(xiàn)其它如sin、tan、%等數(shù)學(xué)運算呢？

另外由于涉及數(shù)學(xué)運算，那么將作為add、sub、mul和div等入?yún)⒌淖兞勘３秩缤瑪?shù)學(xué)公式運算數(shù)般純凈（Persistent/Immutable Data Structure）是必須的，那是否還要引入immutable.js呢？（D.js現(xiàn)在采用按需生成副本的方式，可預(yù)見隨著代碼量的增加，這種方式會導(dǎo)致整體代碼無法維護）

依照我的尿性，D.js將采取不定期持續(xù)更新的策略（待我理解Persistent/Immutable Data Structure后吧:)）。歡迎各位指教！

尊重原創(chuàng)，轉(zhuǎn)載請注明來自：http://www.cnblogs.com/fsjohnhuang/p/5115672.html ^_^肥子John

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