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}的二進制再轉成十進制是${to10(binaryMN)}`); console.log(`${accuracyMN}的二進制是再轉成十進制是${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);
因爲JavaScript
中沒有將小數的二進制
轉換成十進制
的方法,因而手動實現了一個。node
計算機中全部的數據都是以二進制
存儲的,因此在計算時計算機要把數據先轉換成二進制
進行計算,而後在把計算結果轉換成十進制
。git
由上面的代碼不難看出,在計算0.1+0.2
時,二進制
計算髮生了精度丟失,致使再轉換成十進制
後和預計的結果不符。github
其實有些標題黨了,一個函數並不能讓你深刻理解,還得繼續看下面...安全
0.1
和0.2
的二進制都是以1100無限循環的小數,下面逐個來看JS幫咱們計算所得的結果:函數
0.1的二進制:工具
0.0001100110011001100110011001100110011001100110011001101
0.2的二進制:網站
0.001100110011001100110011001100110011001100110011001101
理論上講,由上面的結果相加應該::編碼
0.0100110011001100110011001100110011001100110011001100111
實際JS計算獲得的0.1+0.2的二進制spa
0.0100110011001100110011001100110011001100110011001101
做爲一個代碼強迫症的我又產生的新的問題:code
Why js計算出的 0.1的二進制 是這麼多位而不是更多位???Why js計算的(0.1+0.2)的二進制和咱們本身計算的(0.1+0.2)的二進制結果不同呢???
Why 0.1的二進制 + 0.2的二進制 != 0.3的二進制???
小數的二進制
大多數都是無限循環的,JavaScript
是怎麼來存儲他們的呢?
在ECMAScript®語言規範中能夠看到,ECMAScript
中的Number
類型遵循IEEE 754
標準。使用64位固定長度來表示。
事實上有不少語言的數字類型都遵循這個標準,例如JAVA
,因此不少語言一樣有着上面一樣的問題。
因此下次遇到這種問題不要上來就噴JavaScript
...
有興趣能夠看看下這個網站http://0.30000000000000004.com/,是的,你沒看錯,就是http://0.30000000000000004.com/!!!
IEEE754標準包含一組實數的二進制表示法。它有三部分組成:
三種精度的浮點數各個部分位數以下:
JavaScript
使用的是64位雙精度浮點數編碼,因此它的符號位
佔1
位,指數位佔11
位,尾數位佔52
位。
下面咱們在理解下什麼是符號位
、指數位
、尾數位
,以0.1
爲例:
它的二進制爲:0.0001100110011001100...
爲了節省存儲空間,在計算機中它是以科學計數法表示的,也就是
1.100110011001100...
X 2-4
若是這裏很差理解能夠想一下十進制的數:
1100
的科學計數法爲11
X 102
因此:
符號位
就是標識正負的,1
表示負
,0
表示正
;
指數位
存儲科學計數法的指數;
尾數位
存儲科學計數法後的有效數字;
因此咱們一般看到的二進制,實際上是計算機實際存儲的尾數位。
因爲尾數位只能存儲52
個數字,這就能解釋toString(2)
的執行結果了:
若是計算機沒有存儲空間的限制,那麼0.1
的二進制
應該是:
0.00011001100110011001100110011001100110011001100110011001...
科學計數法尾數位
1.1001100110011001100110011001100110011001100110011001...
可是因爲限制,有效數字第53
位及之後的數字是不能存儲的,它遵循,若是是1
就向前一位進1
,若是是0
就捨棄的原則。
0.1的二進制科學計數法第53位是1,因此就有了下面的結果:
0.0001100110011001100110011001100110011001100110011001101
0.2
有着一樣的問題,其實正是因爲這樣的存儲,在這裏有了精度丟失,致使了0.1+0.2!=0.3
。
事實上有着一樣精度問題的計算還有不少,咱們沒法把他們都記下來,因此當程序中有數字計算時,咱們最好用工具庫來幫助咱們解決,下面是兩個推薦使用的開源庫:
下面咱們再來看上面的其餘兩個問題。
上面的toString
原理幫咱們解答了這個問題,在有效數字第53
位之後的數字將遵循1進0舍
的原則,內存中只容許存儲52
位有效數字。
咱們本身計算的0.1+0.2::
0.0100110011001100110011001100110011001100110011001100111
實際上這個結果的有效數字已經超過了52
位,咱們要從末尾進行1進0舍
獲得下面的結果
0.0100110011001100110011001100110011001100110011001101
由與IEEE 754
雙精度64位規範的限制:
指數位
能表示的最大數字:1023
(十進制)
尾數位
能表達的最大數字即尾數位都位1
的狀況
因此JavaScript能表示的最大數字即位
1.111...
X 21023 這個結果轉換成十進制是1.7976931348623157e+308
,這個結果即爲Number.MAX_VALUE
。
JavaScript中Number.MAX_SAFE_INTEGER
表示最大安全數字,計算結果是9007199254740991
,即在這個數範圍內不會出現精度丟失(小數除外),這個數其實是1.111...
X 252。
咱們一樣能夠用一些開源庫來處理大整數:
其實官方也考慮到了這個問題,bigInt
類型在es10
中被提出,如今Chrome
中已經可使用。
BigInt
是第七種原始類型。
BigInt
是一個任意精度的整數。這意味着變量如今能夠計算9007199254740991
即最大安全整數以上的數字。
const b = 1n; // 追加 n 以建立 BigInt
在過去,不支持大於 9007199254740992
的整數值。若是超過,該值將鎖定爲 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
typeof
typeof 10; ⇨ 'number' typeof 10n; ⇨ 'bigint'