一个函数让你看懂 'Why 0.1+0.2!=0.3'
話不多說,先上代碼
function judgeFloat(n, m) {const binaryN = n.toString(2);const binaryM = m.toString(2);console.log(`${n}的二進制是 ${binaryN}`);console.log(`${m}的二進制是 ${binaryM}`);const MN = m + n;const accuracyMN = (m * 100 + n * 100) / 100;const binaryMN = MN.toString(2);const accuracyBinaryMN = accuracyMN.toString(2);console.log(`${n}+${m}的二進制是${binaryMN}`);console.log(`${accuracyMN}的二進制是 ${accuracyBinaryMN}`);console.log(`${n}+${m}的二進制再轉(zhuǎn)成十進制是${to10(binaryMN)}`);console.log(`${accuracyMN}的二進制是再轉(zhuǎn)成十進制是${to10(accuracyBinaryMN)}`);console.log(`${n}+${m}在js中計算是${(to10(binaryMN) === to10(accuracyBinaryMN)) ? '' : '不'}準確的`);}function to10(n) {const pre = (n.split('.')[0] - 0).toString(2);const arr = n.split('.')[1].split('');let i = 0;let result = 0;while (i < arr.length) {result += arr[i] * Math.pow(2, -(i + 1));i++;}return result;}judgeFloat(0.1, 0.2);judgeFloat(0.6, 0.7); 復(fù)制代碼由于JavaScript中沒有將小數(shù)的二進制轉(zhuǎn)換成十進制的方法,于是手動實現(xiàn)了一個。
先來一個簡單的結(jié)論
計算機中所有的數(shù)據(jù)都是以二進制存儲的,所以在計算時計算機要把數(shù)據(jù)先轉(zhuǎn)換成二進制進行計算,然后在把計算結(jié)果轉(zhuǎn)換成十進制。
由上面的代碼不難看出,在計算0.1+0.2時,二進制計算發(fā)生了精度丟失,導(dǎo)致再轉(zhuǎn)換成十進制后和預(yù)計的結(jié)果不符。
其實有些標題黨了,一個函數(shù)并不能讓你深入理解,還得繼續(xù)看下面...
對結(jié)果的分析—更多的問題
0.1和0.2的二進制都是以1100無限循環(huán)的小數(shù),下面逐個來看JS幫我們計算所得的結(jié)果:
0.1的二進制:
0.0001100110011001100110011001100110011001100110011001101 復(fù)制代碼0.2的二進制:
0.001100110011001100110011001100110011001100110011001101 復(fù)制代碼理論上講,由上面的結(jié)果相加應(yīng)該::
0.0100110011001100110011001100110011001100110011001100111 復(fù)制代碼實際JS計算得到的0.1+0.2的二進制
0.0100110011001100110011001100110011001100110011001101 復(fù)制代碼作為一個代碼強迫癥的我又產(chǎn)生的新的問題:
Why js計算出的 0.1的二進制 是這么多位而不是更多位???
Why js計算的(0.1+0.2)的二進制和我們自己計算的(0.1+0.2)的二進制結(jié)果不一樣呢???
Why 0.1的二進制 + 0.2的二進制 != 0.3的二進制???
js對二進制小數(shù)的存儲方式
小數(shù)的二進制大多數(shù)都是無限循環(huán)的,JavaScript是怎么來存儲他們的呢?
在ECMAScript?語言規(guī)范中可以看到,ECMAScript中的Number類型遵循IEEE 754標準。使用64位固定長度來表示。
事實上有很多語言的數(shù)字類型都遵循這個標準,例如JAVA,所以很多語言同樣有著上面同樣的問題。
所以下次遇到這種問題不要上來就噴JavaScript...
有興趣可以看看下這個網(wǎng)站0.30000000000000004.com/,是的,你沒看錯,就是0.30000000000000004.com/!!!
IEEE 754
IEEE754標準包含一組實數(shù)的二進制表示法。它有三部分組成:
-
符號位
-
指數(shù)位
-
尾數(shù)位
三種精度的浮點數(shù)各個部分位數(shù)如下:
JavaScript使用的是64位雙精度浮點數(shù)編碼,所以它的符號位占1位,指數(shù)位占11位,尾數(shù)位占52位。
下面我們在理解下什么是符號位、指數(shù)位、尾數(shù)位,以0.1為例:
它的二進制為:0.0001100110011001100...
為了節(jié)省存儲空間,在計算機中它是以科學(xué)計數(shù)法表示的,也就是
1.100110011001100... X 2-4
如果這里不好理解可以想一下十進制的數(shù):
1100的科學(xué)計數(shù)法為11 X 102
所以:
符號位就是標識正負的,1表示負,0表示正;
指數(shù)位存儲科學(xué)計數(shù)法的指數(shù);
尾數(shù)位存儲科學(xué)計數(shù)法后的有效數(shù)字;
所以我們通常看到的二進制,其實是計算機實際存儲的尾數(shù)位。
js中的toString(2)
由于尾數(shù)位只能存儲52個數(shù)字,這就能解釋toString(2)的執(zhí)行結(jié)果了:
如果計算機沒有存儲空間的限制,那么0.1的二進制應(yīng)該是:
0.00011001100110011001100110011001100110011001100110011001... 復(fù)制代碼科學(xué)計數(shù)法尾數(shù)位
1.1001100110011001100110011001100110011001100110011001... 復(fù)制代碼但是由于限制,有效數(shù)字第53位及以后的數(shù)字是不能存儲的,它遵循,如果是1就向前一位進1,如果是0就舍棄的原則。
0.1的二進制科學(xué)計數(shù)法第53位是1,所以就有了下面的結(jié)果:
0.0001100110011001100110011001100110011001100110011001101 復(fù)制代碼0.2有著同樣的問題,其實正是由于這樣的存儲,在這里有了精度丟失,導(dǎo)致了0.1+0.2!=0.3。
事實上有著同樣精度問題的計算還有很多,我們無法把他們都記下來,所以當(dāng)程序中有數(shù)字計算時,我們最好用工具庫來幫助我們解決,下面是兩個推薦使用的開源庫:
-
number-precision
-
mathjs/
下面我們再來看上面的其他兩個問題。
Why JavaScript計算出的 0.1的二進制 是這么多位而不是更多位???
上面的toString原理幫我們解答了這個問題,在有效數(shù)字第53位以后的數(shù)字將遵循1進0舍的原則,內(nèi)存中只允許存儲52位有效數(shù)字。
Why JavaScript計算的(0.1+0.2)的二進制和我們自己計算的(0.1+0.2)的二進制結(jié)果不一樣呢???
我們自己計算的0.1+0.2::
0.0100110011001100110011001100110011001100110011001100111 復(fù)制代碼實際上這個結(jié)果的有效數(shù)字已經(jīng)超過了52位,我們要從末尾進行1進0舍得到下面的結(jié)果
0.0100110011001100110011001100110011001100110011001101 復(fù)制代碼JavaScript能表示的最大數(shù)字
由與IEEE 754雙精度64位規(guī)范的限制:
指數(shù)位能表示的最大數(shù)字:1023(十進制)
尾數(shù)位能表達的最大數(shù)字即尾數(shù)位都位1的情況
所以JavaScript能表示的最大數(shù)字即位
1.111...X 21023 這個結(jié)果轉(zhuǎn)換成十進制是1.7976931348623157e+308,這個結(jié)果即為Number.MAX_VALUE。
最大安全數(shù)字
JavaScript中Number.MAX_SAFE_INTEGER表示最大安全數(shù)字,計算結(jié)果是9007199254740991,即在這個數(shù)范圍內(nèi)不會出現(xiàn)精度丟失(小數(shù)除外),這個數(shù)實際上是1.111...X 252。
我們同樣可以用一些開源庫來處理大整數(shù):
- node-bignum
- node-bigint
其實官方也考慮到了這個問題,bigInt類型在es10中被提出,現(xiàn)在Chrome中已經(jīng)可以使用。
bigInt類型
BigInt 是第七種原始類型。
BigInt 是一個任意精度的整數(shù)。這意味著變量現(xiàn)在可以計算9007199254740991即最大安全整數(shù)以上的數(shù)字。
const b = 1n; // 追加 n 以創(chuàng)建 BigInt 復(fù)制代碼在過去,不支持大于 9007199254740992 的整數(shù)值。如果超過,該值將鎖定為MAX_SAFE_INTEGER + 1:
const limit = Number.MAX_SAFE_INTEGER; ? 9007199254740991 limit + 1; ? 9007199254740992 limit + 2; ? 9007199254740992 <--- MAX_SAFE_INTEGER + 1 exceeded const larger = 9007199254740991n; ? 9007199254740991n const integer = BigInt(9007199254740991); // initialize with number ? 9007199254740991n const same = BigInt("9007199254740991"); // initialize with "string" ? 9007199254740991n 復(fù)制代碼typeof
typeof 10; ? 'number' typeof 10n; ? 'bigint' 復(fù)制代碼總結(jié)
以上是生活随笔為你收集整理的一个函数让你看懂 'Why 0.1+0.2!=0.3'的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: ETL工程师知识点
- 下一篇: Ubuntu 16.04.6 LTS 发