※ 引述《lovejomi (JOMI)》之銘言： : a. stackoverflow的作法錯了? : b. 為什麼會把差值當成相等? : c. 到底這個epsilon 最應該用在哪裡呢? : d. 是不是把almost_equal當成一個正解 才是正確的浮點數比較相等呢？ : 我用以下tool 把 epsilon 看他hex form 反推一下 : 他是2^-23 = 0.00000011920928955078125f乍看之下跟gcc定義一致 : https://www.h-schmidt.net/FloatConverter/IEEE754.html : 觀念上有些錯誤 : 請大家修正一下 : 謝謝 浮點數雖然可能因為實作不同而有差異性，但扣除一些特殊的值之後 浮點數型別能毫無誤差表示的數值跟整數能表示的數值性質相似 都是落在數線上的離散格子點. 跟整數不同的地方在於，相鄰的整數格子點間的距離是相等的 但是相鄰的浮點數格子點間的距離可能不相等 (與指數的大小和 epsilon 有關: epsilon * base^exp) 整數: | | | | | | | | | | (相鄰的整數間都是等寬) 浮點數: | | | | | | | | | | | | | | | (相鄰的浮點數間距離，會隨著浮點數的大小而可能有所不同) 要透過浮點數做運算時大概有三個步驟 1. 將要計算的數字轉換成浮點數可精確表示的格子點 (可能產生誤差) 2. 對這些在格子點上的數字們做運算 3. 將算出來的結果存在浮點數可精確表示的格子點上 (可能產生誤差) 以對 x + y 做計算為例. 因為 x 或 y 可能不是目前所用浮點數實作可以精確表達的數字 (例如 0.1 在常見的浮點數實作上無法準確落在格子點上) 所以首先要將 x 與 y 轉換到各自最近的浮點數格子點上，此時就產生誤差 (例如 0.1 + 0.1 時會先將兩個 0.1 都轉換到最近的浮點數格子點，造成運算完的結果可能不完全等於 0.2) 假設將 x 轉換到 x', y 轉換到 y'，則令 x = x' + dx (dx 表示 x 轉換到格子點 x' 產生的誤差) y = y' + dy (dy 表示 y 轉換到格子點 y' 產生的誤差) 因此當我們運算 x + y 時，實質上是用 x' + y' 去運算 同時運算的結果，也可能不落在格子點上 假設我們將 x' + y' 運算的結果取名為 z，則將 z 轉換到最近的格子點 z' 的話 z = z' + dz (dz 表示 z 轉換到格子點 z' 產生的誤差) 綜合以上所說， 原本我們想要算 x + y ，也就是 (x' + dx) + (y' + dy) = x' + y' + dx + dy (例如 0.1 + 0.1) 最後卻變成是算出 z'， 也就是 z - dz = x' + y' - dz (例如 0.1 + 0.1 的結果) 最後原本想算的和與真正算出的結果間的誤差就變成是 |x + y - z'| = |dx + dy + dz| 如果 |dx + dy + dz| == 0 的話，去比較 x + y == z' 通常是沒問題 但是不為 0 的時候，dx + dy + dz 和的大小範圍就會影響我們判斷是否可能相等時的條件範圍 而我們怎麼知道 dx + dy + dz 的大小範圍呢 ? 這和當時 x, y, z 的大小有關 因為誤差大小通常不會大於浮點數格子點間一半的距離 而浮點數格子點間距離會隨指數與 epsilon 不同而不同 epsilon 跟浮點數實作有關，而指數大小則與目前的值大小有關 這邊 epsilon 表示的是 1 跟下一個比 1 大的浮點數格子點的距離 可以想成不考慮 base^exp 的大小的情況下 (exp = 0)，兩個浮點數格子點間最近的距離 (當然這裡我們去掉了一些特殊的值，例如 subnormal number, +-0) 但是因為 base^exp 會放大格子間距離，所以格子間距離要多乘上 base^exp 而與 epsilon * base^exp 有關 因此考慮 dx + dy + dz 這誤差可能的範圍時，要考慮 dx, dy, dz 的大小 而 dx, dy, dz 的大小與 x, y, z 當時的值有關 (影響 base^exp 的大小) 此外還要考慮 epsilon 跟允許的誤差計算次數等 當然我知道我這邊舉 0.1 當例子可能不好 (通常是 subnormal number)，只是為了方便理解 草草寫寫，有錯誤疏漏也請不吝指教 ※ 編輯: Feis (140.122.83.198), 09/19/2018 00:47:44