JS中如何便捷地修復精度偏差？

時間 2019-11-06

原文原文鏈接

小夥伴常常會遇到相似0.1+0.2===0.3返回false的問題，這種問題很是隱晦。有時候又很明顯，好比在價格展現的地方，忽然某個地方長出了一長串的尾數（3.2元打個8折，原本預期展現2.56元，結果顯示2.5600000000000005元，用戶恐怕是要被嚇跑的）。html

爲何

計算能力那麼強的電腦，爲何會出現這種低級錯誤呢？git

這屬於底層的問題，咱們先看一下js是怎麼表示數值的。具體能夠參考這篇文章：《爲何0.1+0.2不等於0.3？》，緣由部分就再也不贅述，下面，說一下咱們能夠怎麼用工具/代碼進行分析。github

咱們能夠經過toString方法獲得數值的二進制表示。算法

(0.1).toString(2); // "0.0001100110011001100110011001100110011001100110011001101"
(0.2).toString(2); // "0.001100110011001100110011001100110011001100110011001101"
複製代碼

"0.0001100110011001100110011001100110011001100110011001101"對應的是0.1嗎？咱們找一個帶小數的二進制轉十進制工具確認一下。計算機二進制表示的0.1約等於0.10000000000000000555(21個數字)，0.2約等於0.2000000000000000111（20個數字）結合十進制轉二進制的算法，能夠推斷出，0.1在二進制中是無限循環小數（循環節是0011），計算機用雙精度表示時作了舍入的近似，因而產生了舍入偏差（round-off error）。經過以上工具分析，咱們也獲得了相同的結論。bash

如何解決

解決精度問題的庫很多，如decimal.js，可爲 JavaScript提供十進制類型的任意精度數值。官網：mikemcl.github.io/decimal.js/ GitHub：github.com/MikeMcl/dec…函數

實際上，須要用到很是大的數字同時要求很是高的精度，情形並很少，並且已經存在現成的「輪子」。更多的是像：0.1+0.2、3.2*0.8之類的場景。而這些場景理論上是能夠經過控制合理的精度進行四捨五入去避免的。若是一兩個函數能解決，就沒有必要引入一個庫了。固然，這裏隱含了一個前提：這個函數要足夠健壯，同時性能良好。工具

首先要解決的問題是，合理的精度應該是多少？根據IEEE 754，咱們知道，一個64位的雙精度浮點數的有效數字大約是16個（十進制, (Math.pow(2,53)+'').length）），2個數進行四則運算後，結果的有效數字大約是15個，咱們作四捨五入保留15個數字就能夠知足要求。性能

第一個版本單元測試

function fixPrecision(num) {
  var pointIndex = ("" + num).indexOf(".");
  if (num < 0) {
    pointIndex--;
  }
  var ans = (+num).toFixed(15 - pointIndex); // 根據整數長度部分，動態調整精度
  return parseFloat(ans);
}
fixPrecision(0.1+0.2); // 0.3
複製代碼

在單元測試中發現一個反例：fixPrecision(1000.9-1000.6) !== 0.3 爲何呢？咱們直接在命令行把1000.9-1000.6的結果打印出來發現是：0.2999999999999545。咱們增長整數的個數看看有沒有什麼規律測試

0.9-0.6               // 0.30000000000000004  (輸入的整數部分0位，結果的有效數字不超過16位)
1.9-1.6               // 0.2999999999999998   (輸入的整數1位，結果的有效數字不超過15位)
10.9-10.6             // 0.3000000000000007   (輸入的整數2位，結果的有效數字不超過14位)
100.9-100.6           // 0.30000000000001137  (輸入的整數3位，結果的有效數字不超過13位)
1000.9-1000.6         // 0.2999999999999545   (輸入的整數4位，結果的有效數字不超過13位)
10000.9-10000.6       // 0.2999999999992724   (輸入的整數5位，結果的有效數字不超過12位)
100000.9-100000.6     // 0.29999999998835847  (輸入的整數6位，結果的有效數字不超過10位)
1000000.9-1000000.6   // 0.30000000004656613  (輸入的整數7位，結果的有效數字不超過10位)
10000000.9-10000000.6 // 0.30000000074505806  (輸入的整數8位，結果的有效數字不超過8位)
複製代碼

這裏的有效數字指的是調用toFixed能獲得預期結果的最大輸入數字。規律仍是比較明顯的，輸入的整數部分每增長1位，結果小數部分的有效數字就相應減小約1位。這樣看，網上有些實現是經過把小數轉換成整數，計算完再轉回對應小數，本質上對精度是沒有提高的。道理也很明顯，0.1*10變成1，即從一個不能精準表示的數字變成一個能精準表示的數字，中間必然存在舍入。

因此咱們，對於加減法，有效數字的處理能夠優化成：15 - Math.max(輸入數字1的整數個數, 輸入數字2的整數個數, 輸出數字的整數個數)。

輸出數字的精度受到輸入數字的影響，這個問題，在乘法和除法中不存在。因爲除法能夠用乘法表示，咱們這裏只討論乘法。好比0.1*0.2，若是計算機用a表示0.1，b表示偏差，即 0.1 = a+b，那麼0.1*0.2=(a+b)*2*(a+b) = 2a^2 + 4ab + 2b^2，計算機算的是a*2*a 偏差是4ab + 2b^2=(4a+2b)*b因爲a約等於0.1,b約等於0，因此(4a+2b)<1，因此偏差小於b，即比原來任意一個乘數的偏差還小。

以上是一個特殊的場景，咱們也能夠用一種近似的方法來證實一種通用場景。上面咱們有結論：有效數字與整數的數量級相關。咱們近似表示，被乘數10^a+10^(a-16)，乘數10^b+10^(b-16)，其中a、b分別表示整數對應的數量級（如，10對應的a=1，0.1對應的a=-1，10^a表示有效值，10^(a-16)表示偏差）。那麼兩數相乘結果是10^(a+b)+2*10^(a+b-16)+10^(b+a-32),其中10^(a+b)爲結果的整數部分，偏差數量級爲10^Math.max(b+a-16, b+a-32) = 10^(b + a - 16)。由此，能夠看出對於乘法和除法，修復精度偏差只須要考慮輸出數據的整數部分數字長度便可。

第二個版本

// 適合處理長度不超過15個數字的場景。（15個數字即整數的位數加上小數的位數不超過15位，
// 如：1234567890.12345 或者 12345.0123456789，之類）
/** *修復精度 * * @param {number} num 需修復的浮點數 * @param {number|undefined} intLength 計算前入參的整數長度部分，用於動態調整精度 * @returns */
function fixPrecision(num, intLength) {
  // 根據整數長度部分，動態調整精度
  return +(+num).toFixed(15 - Math.max(intLength || 0, getIntLength(num)));
}
/** * 獲取整數部分數字長度 * * @param {number} num * @returns {number} */
function getIntLength(num) {
  var pointIndex = ("" + num).indexOf(".");
  return num < 0 ? pointIndex - 1 : pointIndex;
}
function getMaxIL(a, b) {
  return Math.max(getIntLength(a), getIntLength(b));
}


function add(a, b) {
    return fixPrecision(a + b, getMaxIL(a, b));
}

add(1000.9, -1000.6); // 0.3
複製代碼