關於 JavaScript 的 精度丟失 與 近似舍入

1、背景

---

最近作 dashborad 圖表時，涉及計算小數且四捨五入精確到 N 位。後發現 js 算出來的結果跟我預想的不同，看來這裏面並不簡單……

2、JS 與 精度

---

一、精度處理

首先明確兩點：

• 一、小數纔會涉及精度的概念
• 二、小數的（存儲和）運算涉及 JS 的精度處理

在現實中，咱們運算小數，不會出現任何問題。可是 JS （編程語言）裏，卻不是這樣。

二、精度丟失

例如，在 JS 裏執行：

0.1 + 0.2
0.30000000000000004

0.3 - 0.1
0.19999999999999998

0.1 * 0.1
0.010000000000000002

0.3 / 0.1
2.9999999999999996

能夠看出，JS 運算小數的結果，並非咱們預想的那樣。這就是精度丟失的問題。

（1）問：精度丟失會引起什麼問題？

答：

• 一、讓判斷等於（===）的邏輯出錯。好比讓 0.1 + 0.2 === 0.3 爲 false
• 二、讓原本能夠預想到的結果精度變的特別大，小數點後位數特別長。好比若要前端顯示，會特別難看。

（2）問：爲何會出現精度丟失？

答：這跟浮點數在計算機內部（用二進制存儲）的表示方法有關。

JS 採用 IEEE 754 標準的 64 位雙精度浮點數表示法，這個標準是20世紀80年代以來最普遍使用的浮點數運算標準，爲許多CPU與浮點運算器所採用，也被不少語言如 java、python 採用。

這個標準，會讓絕大部分的十進制小數都不能用二進制浮點數來精確表示（事實上，根本沒有什麼標準能夠精確表示浮點數）。通常狀況下，你輸入的十進制小數僅由實際存儲在計算機中的近似的二進制浮點數表示。

然而，許多語言在處理的時候，在必定偏差範圍內（一般極小）會將結果修正爲正確的目標數字，而不是像 JS 同樣將存在偏差的真實結果轉換成最接近的小數輸出。

具體原理能夠看《浮點數的二進制表示 —— 阮一峯》，這裏不贅述了。

（3）問：怎麼避免精度丟失？

方法一：中途變成整數來計算

好比咱們要計算 0.1 + 0.2，就先把數字所有乘以 10 使之變成整數，再相加，最後把結果除以 10。

由於整數是不會出現精度丟失的問題。（何況整數根本就沒有精度）
其實不少第三方的庫，原理也是用的這個。

方法二：使用第三方庫

• Math.js
• decimal.js
• big.js
• bignumber.js

方法三：使用 toFixed() 函數（推薦）

console.log(parseFloat((0.3 + 0.1).toFixed(1))) // 0.4

注意：toFixed() 最好跟 parseFloat() 搭配使用。由於 toFixed 返回的是字符串。

問：toFixed() 爲何要返回字符串，而不是小數？【重點】
答：由於 JavaScript 的數據類型，關於數字的只有 number 類型（不像 C 語言 or 數據庫等還分 int、float、double），而對於 number 類型來講, 會忽略前置0和小數點後的後置0（好比 001 是 1; 1.1000 是 1.1）。

在下面還會繼續介紹 toFixed() 的關於舍入的特性。

3、JS 與 近似計算方法

---

在上面提到的：

• 精度計算
• 精度丟失

都會有可能讓精度發生變化（即小數點後位數變化）。若是咱們須要統一精度，那就須要用到近似（計算）方法。

一、四捨五入

（1）規則

四捨五入是最多見的近似計算方法，具體規則顧名思義，不贅述了。

（2）Math.round()

給定數字的值四捨五入到最接近的整數。

Math.Round(2.4) // 2
Math.Round(2.5) // 3

（3）_.round() —— lodash

給定數字的值四捨五入到最接近的數（能夠是小數）。

lodash 的這個方法，我看了源碼，底層也是調用的 Math.round()，只是加了一些額外功能，好比第二個參數，能夠指定四捨五入的精度。

const _ = require('lodash');
_.round(1.04, 1) //1
_.round(1.05, 1) //1.1

（4）四捨五入真的公平嗎？【重點】

由於本身很小的時候就在學校學到了四捨五入，一直想固然的認爲四捨五入是公平的，等到如今細想的時候，才發現，真的不公平。

例如，想象一個場景，你的餘額寶，天天會自動結算利息，可是可能（按照利息規則）算出來的值的小數有不少位，假設支付寶只支持到角，那麼支付寶系統幫你記帳的時候，確定會給你近似計算，若是他用的是四捨五入的方法：

const _ = require('lodash');
console.log(_.round(1.01, 1)) //1 （我虧了0.01）
console.log(_.round(1.02, 1)) //1 （我虧了0.02）
console.log(_.round(1.03, 1)) //1 （我虧了0.03）
console.log(_.round(1.04, 1)) //1 （我虧了0.04）
console.log(_.round(1.05, 1)) //1.1 （我賺了了0.05）
console.log(_.round(1.06, 1)) //1.1 （我賺了0.04）
console.log(_.round(1.07, 1)) //1.1 （我賺了0.03）
console.log(_.round(1.08, 1)) //1.1 （我賺了0.02）
console.log(_.round(1.09, 1)) //1.1 （我賺了0.01）

首先，1 塊錢整和 2 塊錢整能夠不用考慮，其次，若是假設 1.01 到 1.09 這 9 個數出現的機率一致。那麼最後支付寶確定要虧本，由於 1.05 劃分到 1.1 是不公平的。

也能夠畫一個數軸來體現：

那麼如何作到更公平的近似計算呢？能夠用下面介紹的銀行家舍入。

二、銀行家舍入

國際通行的是 銀行家舍入（Banker's rounding）算法 。

是 IEEE 規定的舍入標準。所以全部符合 IEEE 標準的語言都應該是採用這一規則的。

（1）規則

銀行家舍入又稱四捨六入五取偶（又稱四捨六入五留雙）法。

因此規則就是：四捨六入五考慮，五後非空就進一，五後爲空看奇偶，五前爲偶應捨去，五前爲奇要進一。

關鍵就是「五後爲空看奇偶」，由於若是是舍入位是5，不管是舍仍是入都不公平，那就交給它前一位的奇偶性來判斷，由於奇偶性分佈機率是公平的。

固然只能說銀行家舍入算法比四捨五入算法更科學，而不能說它就是絕對正確，而四捨五入就是錯誤的，由於這些結果都是基於統計數據產生的，前提就是這些數據搖符合隨機性分佈的要求。

（2）使用

目前 JS 上原生不支持，若是想使用：

• 一、本身實現
• 二、使用第三方 npm 包，如 bankers-rounding

三、toFixed

toFixed() 部分符合銀行家舍入的規則。

（1）四捨六入

符合

（2）五後非空就進一

符合

（3）五後爲空看奇偶，五前爲偶應捨去，五前爲奇要進一

部分符合

//                           //toFixed結果  //銀行家舍入結果
console.log(1.05.toFixed(1)) //1.1（+0.05） 1.0（-0.05）
console.log(1.15.toFixed(1)) //1.1（-0.05） 1.2（+0.05）
console.log(1.25.toFixed(1)) //1.3（+0.05） 1.2（-0.05）
console.log(1.35.toFixed(1)) //1.4（+0.05） 1.4（+0.05）
console.log(1.45.toFixed(1)) //1.4（-0.05） 1.4（-0.05）
console.log(1.55.toFixed(1)) //1.6（+0.05） 1.6（+0.05）
console.log(1.65.toFixed(1)) //1.6（-0.05） 1.6（-0.05）
console.log(1.75.toFixed(1)) //1.8（+0.05） 1.8（+0.05）
console.log(1.85.toFixed(1)) //1.9（+0.05） 1.8（-0.05）
console.log(1.95.toFixed(1)) //1.9（-0.05） 2.0（+0.05）
//                           //總計(+0.1)   //總計(0)

能夠看出 toFixed 確定是不遵照四捨五入的，可是也跟銀行家舍入算法有出入。（具體爲何是這樣的計算方法，鄙人並非弄清楚，待寫）

四、其餘 近似計算 函數

• Math.ceil()：向上舍入（取整）
• Math.floor()：向下舍入（取整）
• 等等……