JS與數

本篇將討論JS在數字類型方面的一些表現和特性

1. 0.1 + 0.2不等於0.3

這是一個老生常淡的問題，甚至有一個網站叫：https://0.30000000000000004.com，這個也就是0.1 + 0.2的值，以下圖所示：

在控制檯運行獲得的結果帶了個尾巴，但0.1是0.1，0.2是0.2，0.3結果也是0.3，爲何0.1 + 0.2就不等於0.3了呢？

並且咱們發現0.01 + 0.09 + 0.2這個結果又等於0.3了：

緣由很簡單，由於0.1存儲的值比實際值大了一點，0.2也是大了一點（差值比0.1大一倍），兩個相加就大不少了，多出來的就是那個尾巴。爲何0.1不可以被準確存儲呢？由於計算機都是二進制的，在十進制能表示的數不必定能被二進制精確表示，就好像在十進制裏面沒法準確表示1/3同樣，而在三進制裏面0.1便表示1/3了。在二進制裏面可以被精確表示都必須得是二的倍數的組合，如二進制的0.1表示十進制的0.5，0.11便表示0.75（ = 0.5 + 0.25），0.111表示0.875（ = 0.5 + 0.25 + 0.125），假設如今要存儲0.625那麼可以被精確表示爲二進制的0.101，若是要表示0.626呢？那麼應該是經過後面的小數位相加拼湊，讓其儘量逼近0.626. 這個時候就不是精確表示了，這個事情就是編譯器的工做。

十進制的0.1和0.2究竟被存儲成什麼呢？咱們能夠寫一段C代碼，而後使用gcc編譯器生成彙編代碼即可知道存儲的值了，以下代碼所示：

// add.c
int main() {
  double a = 0.1;
  double b = 0.2;
  double c = 0.1 + 0.2;
  return 0; 
}
// 運行
gcc -S add.c -o add.s複製代碼

打開add.s這個文件，以下圖所示：

.quad指令表示這是一個64位的數字，這裏是雙精度浮點數存儲的二進制的值的十進制數值，也就是說用這個數字轉成的二進制就是內存裏面符合IEEE 754浮點數的存儲：

咱們再反過來看一下這兩個數的精確值是多少，以下圖計算所示（根據浮點數尾數、階碼的計算規則）：

或者使用JS和toFixed也能看到實際的值：

能夠看到，0.1的存儲其實是大了0.55e-17，而0.2大了1.11e-17，兩個相加因爲二進制相加時階碼要對齊（0.1進階末位是1，進了一位，詳細過程推導可見：爲何0.1 + 0.2不等於0.3？），致使精度舍入，因此最後結果便爲了4e-17。

這個時候你可能會說爲何0.2打印出來不是0.20000000000000001呢？1e-17和4e-17差異就那麼大嗎？從V8源碼（fatt_dtoa.cc）能夠看到浮點數轉成字符串的時候對尾數的處理有一個很是複雜的過程，基本上要符合儘量地短以及找到一個接近它的數：

// The digits in the buffer are the shortest representation possible: no
// 0.09999999999999999 instead of 0.1. The shorter representation will even be
// chosen even if the longer one would be closer to v.複製代碼

具體過程不去深刻研究，但能夠確定的是4e-17已經超過了它能把尾數省掉的容忍度，所以轉成字符串的時候就帶了個尾巴。

同時這也解釋了爲何(2.55).toFixed(1)的值是2.5而不是2.6，由於2.55存儲的值比實際的值小，在四捨五入的時候是嚴格按照滿就進位的規則，因此結果就(2.54999999).toFixed(1)的結果同樣了，具體可見《爲何(2.55).toFixed(1)等於2.5？》

2. 小數和整數之間的自動切換

JS相對於其它編程語言來講有一個比較方便的特性，就是Number類型即能表示整數也能表示小數，使用的時候不區分究竟是整型仍是浮點型，例如0.9 + 0.1兩個浮點型相加就會變成一個整型的值1，若是是整型的話在轉成字符串的時候末尾就不會給加上無用的0。因此數在JS裏面到底是怎麼表示的呢？從V8源碼能夠看到，全部的數都是用64位二進制表示的，也就是說浮點數都是雙精度的，浮合IEEE 754的規定，和其它語言一致。而整數也是用浮點數的結構表示的，例如若是要表示整數2，那麼尾數爲0，階碼值爲1，即1.0 * 2 ^ 1 = 2，若是要表示整數3，那麼尾數應當爲0.1，階碼也爲1，即1.1 * 2 ^ 1 = 0b11 = 3（注意浮點數的尾數按規定都是默認加1）。經過控制階碼（乘方或者說移位），就能把尾數部分變成整數。

也就是說JS是利用尾數部分來表示整數的，尾數總共有52位，加上默認的1，總共有53位，因此JS最大能表示精確的整數便爲2 ^ 53 - 1即：

這個數約等於9e16，這也就是爲何說雙精度浮點數最多的精確位只有1五、16位，上面0.1 + 0.2打印的結果帶了4e-17的尾巴，並不能說JS出錯了，而是第17位是不精確的，不可以依賴第17位的結果。那既然不能保證準確性，爲啥JS要把它打印出來呢？實際上這個取決於使用的人怎麼用了，如第一點所說，轉字符串的時候JS只是負責儘量地準確。

同時這也是JS的數的一個缺點，最大整數只有16位，而不是64位整型能表示最大的19位，然後端數據庫的id一般是64位整型有可能會超過9e16，這個時候咱們一般會讓後端把id轉成字符串再傳給咱們，不然在JSON.parse的時候一般轉成的整數值就不對了。帶來方便的同時也犧牲了一點功能性。

這個時候你可能會有這個問題，爲何52位尾數會憑空多了一個1，變成了53位，明明只有52位的空間，卻可以表示53位的值，彷佛不符合xxx守恆定律。由於會默認加1，最高位加多了一位，多了這一位的代價是無法表示0了，由於52位尾數表示的最小值是1，因此文檔規定64位全爲0的時候便表示0，若是沒有這個規定的話，全爲0的數應該是最小的那個小數（階碼全爲0便表示最小的階碼-1023）。因此是犧牲掉了最小的小數換取了0的表示，這個小數做用微乎其微，可是卻讓精確值多了一位並且是最高的一位，至關於精確的範圍直接乘以2了。

另一個延伸的問題是爲何Number.EPSILON會是2.2e-16次方：

若是兩個浮點數的差值小於這個數，那麼便認爲這兩個數是相等的，如Math.abs(0.1 + 0.2 - 0.3) < Number.EPSILON，這個數即是精確值的1 unit，即尾數最後一位爲1（前面都爲0）的那個數0.0000...0001，即1 * 2 ^ -52：

3. JS的數是Object嗎？

例如var a = 1，那麼a是一個基礎變量，仍是一個對象Object？咱們看書的常常會有這麼一種說法叫boxing和unboxing，裝盒和拆盒，當調用a的方法如toString時，就會進行裝盒把a變成一個對象，而若是隻是進行加減運算的時候就是一個基礎變量。

在V8裏面能夠看到，V8有一個Object和JSObject的類，Object是V8裏面全部類的根類，而JSObject則表示JS裏面的Object，上面的a變量是V8裏的Object對象，它有一個指針指向它在堆上的內容。V8把對象分爲兩類，一種是棧上的小整數，其它剩下都是堆上的變量（都是須要new或者malloc內存的）。由於小整數（Small Integer）在編程裏面是最經常使用的數，如0，1，2，3，4，5...，因此這種就不要用new了，直接把指針的值變成小整數的值，也就是說這個指針並非指向堆上的一個地址，而就是一個整數的值。這樣能夠節省空間，而且運算也會比較快。

因此a一直都是Number的對象（確實是Object），指針是一個Number類型，可是指針的值不是指向堆上的一個地址，而是實際存儲的整數值。

除了小整數外，大一點的整數是按照上面第2點所說的雙精度存儲的（數據是在堆上的），以及小數和其它全部的對象都是堆上的對象。你可能會問，若是以前是一個小數後來賦值成了一個整數，這個時候怎麼辦？V8會進行存儲結構的轉換。這個時候你可能會說這樣會下降效率？確實，但這是一個平衡考慮的策略。