稍微翻了一下 Java spec
理論上你的數 (0x1.0p-1022) 應該 .toString() 的結果
必須至少要到 "2.2250738585072014e-308" 這麼多位才行
(Java API 有規定轉換結果的精確度必須足以在轉換回來時唯一決定為原數
http://docs.oracle.com/javase/8/docs/api/java/lang/Double.html#toString-double-
可以看上述連結裡有提到)
不過 0x1.0p-1022 這其實是個很特別的 double 浮點數:
它是所謂「正常表示」的 double 裡最小的一個, 也就是 Double.MIN_NORMAL 這數
比它小的浮點數其儲存方式跟一般的浮點數是不一樣的
也因為這樣, 有些手機架構裡為了硬體設計和計算方便
有一個系統層的開關可以控制計算時要不要出現這種數
不要的話比 MIN_NORMAL 小的正數就會全部變成 0
這跟我們的問題的關連就在於
和 0x1.0p-1022 接近的兩個浮點數
比它大的是 0x1.0000000000001p-1022
比它小的是 0x0.fffffffffffffp-1022 (←這個是非標準表示)
它們轉換成十進位是: (多寫幾位以資比較)
0x1.0000000000001p-1022 = 2.22507385807201877...e-308
0x1.0p-1022 = 2.22507385807201383...e-308
0x0.fffffffffffffp-1022 = 2.22507385807200889...e-308
因此在一般的系統裡, 單寫 2.22507385807201 是會錯誤的辨認為最後一個的
所以 Java API 規定必須多輸出一位以資判斷
但在沒有這種小小數的系統裡
它只要能跟比它大的 0x1.0000000000001p-1022 分別就好
最接近 2.22507385807201e-308 的普通浮點數是 0x1p-1022 這就足夠了
====
不過！以上講了這麼半天, 有一個很重要的事實上面沒有提到:
Java 語言定義裡的 double 一直都是有這種小小數的標準 IEEE754 浮點數
所以照理來說只要照著 Java 的規定來的話
不管在哪裡都應該得要能夠使用小小數所以必須做這種分別才對
問題來了: 我們都知道 Android 的 Java 不是標準 Java
它只是拿了 Java 的 API 來自己定義著用而已 (那件官司相信大家記憶猶新)
所以如果 Android 那邊並沒有這種細節規定的話, 那就有可能產生不同結果
而事實上正是這樣:
http://developer.android.com/reference/java/lang/Double.html#toString(double)
Android 官方的 Double.toString(double) 的說明裡只有簡短一行
Returns a string containing a concise, human-readable description of the
specified double value.
跟 Java 官方的 Double.toString(double) (上面的連結) 那麼落落長完全不同
所以根本原因其實並不是硬體結構的關係, 而是 API 規定上根本就不一樣
因此所產生的結果也就有可能不一樣了
(我有點懷疑 Android 版的 toString() 該不會是那種
在科學記號的小數點後面固定取 15 位的懶人但錯誤的實作法...
這樣是並不足以使得轉換回來的所有浮點數都是正確了的)