稍微翻了一下 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 位的懶人但錯誤的實作法... 這樣是並不足以使得轉換回來的所有浮點數都是正確了的) -- 'You've sort of made up for it tonight,' said Harry. 'Getting the sword. Finishing the Horcrux. Saving my life.' 'That makes me sound a lot cooler then I was,' Ron mumbled. 'Stuff like that always sounds cooler then it really was,' said Harry. 'I've been trying to tell you that for years.' -- Harry Potter and the Deathly Hollows, P.308 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.195.39.85 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/java/M.1456596164.A.A41.html ※ 編輯: LPH66 (123.195.39.85), 02/28/2016 02:03:03