Featured image of post 電腦為什麼算不對 0.1 + 0.2？浮點數與捨入誤差的科學
電腦科學 數值計算

電腦為什麼算不對 0.1 + 0.2？浮點數與捨入誤差的科學

引言：令全球程式設計師困惑的「0.1 + 0.2」之謎

幾乎每一位初學程式設計的開發者，在控制台輸入以下程式碼時，都會經歷一次認知衝擊：

1
2
3
4

console.log(0.1 + 0.2);
// 輸出: 0.30000000000000004
console.log(0.1 + 0.2 === 0.3);
// 輸出: false

1
2
3
4

>>> 0.1 + 0.2
0.30000000000000004
>>> 0.1 + 0.2 == 0.3
False

一台每秒能執行數萬億次浮點運算、能渲染逼真3D遊戲、能驅動巨大人工智慧模型的超級電腦，為什麼連小學生都能心算出來的簡單算術題 0.1 + 0.2 = 0.3 都會算錯？

很多新手會下意識地認為這是某種程式語言的底層缺陷或編譯器的偶發故障。然而，無論是蘋果M系列晶片、英特爾至強CPU，還是輝達最新的AI GPU，全球所有的數位計算平台給出的都是完全一致的 0.30000000000000004。

  flowchart TD
    subgraph DecimalWorld ["【人類直覺：十進位世界】"]
        D1["0.1 = 1/10 （有限小數）"]
        D2["0.2 = 2/10 = 1/5 （有限小數）"]
        D3["0.1 + 0.2 = 0.3 （有限小數・完全相等）"]
        D1 --> D3
        D2 --> D3
    end

    subgraph BinaryWorld ["【硬體現實：二進位浮點數世界】"]
        B1["0.1 = (0.0001100110011...)₂\n【無限循環小數】"]
        B2["0.2 = (0.0011001100110...)₂\n【無限循環小數】"]
        B3["53位有限有效數字強制截斷與對齊\nIEEE 754 就近捨入到偶數"]
        B4["最終暫存器數值:\n0.30000000000000004440892098500626..."]
        B1 --> B3
        B2 --> B3
        B3 --> B4
    end

    DecimalWorld -.->|數位電路轉化| BinaryWorld
    style DecimalWorld fill:#e6f3ff,stroke:#0066cc,stroke-width:2px
    style BinaryWorld fill:#ffe6e6,stroke:#cc0000,stroke-width:2px

這一現象揭示了電腦科學的核心妥協：如何用有限的離散位元（0與1）來逼近無限連續的實數世界？

1. 二進位的深淵：為什麼十進位小數會變成無限循環小數？

1.1 十進位中的 $1/3$ 類比

$$\frac{1}{3} = 0.33333333\dots \quad (\text{無限循環小數})$$

無論紙張多大，我們都無法在有限位數內寫完。如果計算機只能顯示8位，它會截斷為 $0.33333333$。將其乘3，我們得到 $0.99999999 \neq 1$。 對於二進位電腦而言，十進位的 0.1 和 0.2 就如同十進位中的 $1/3$ 一樣，是絕對無法除盡的無限小數！

1.2 有限小數的數論充要條件

數論中有一條著名的整除定理：

在 $N$ 進位下，一個既約分數 $\frac{P}{Q}$ 能夠表示為有限小數的充要條件是：分母 $Q$ 的所有質因數，都必須是基數 $N$ 質因數的子集。

  • 十進位基數 $10 = 2 \times 5$： 分母質因數只包含 2 和 5 的分數是有限小數（如 $\frac{1}{2}=0.5, \frac{1}{4}=0.25, \frac{1}{5}=0.2, \frac{1}{10}=0.1$）。
  • 二進位基數 $2$： 基數 2 只有唯一質因數 2！因此在二進位中，只有分母是 $2^k$（如 $\frac{1}{2}, \frac{1}{4}, \frac{1}{8}, \frac{1}{16}$）的分數才能寫成有限小數。

而十進位小數 $0.1 = \frac{1}{10} = \frac{1}{2 \times 5}$，分母中含有質因數 5。因為 2 無法整除 5，0.1 在二進位下必然是不可除盡的無限循環小數：

$$(0.1)_{10} = (0.000110011001100110011\dots)_2$$

電腦記憶體是有限的，必須在某一位強行截斷，微小的捨入誤差就此誕生。

2. IEEE 754 浮點數標準解剖

1985年，電機電子工程師學會制定了 IEEE 754 標準，成為現代所有處理器的硬體浮點規範。

  flowchart TD
    subgraph Binary64Format ["IEEE 754 雙精度浮點數（binary64: 64位元結構）"]
        direction LR
        S["符號位元 (Sign)\n1 bit\n0: 正 (+), 1: 負 (-)"]
        E["指數位元 (Biased Exponent)\n11 bits\n偏移量 Bias = 1023"]
        M["尾數位元 (Significand / Mantissa)\n52 bits\n隱藏最高位『1.』（實際精度53位元）"]
    end

    S --- E --- M
    style Binary64Format fill:#f9f9f9,stroke:#333,stroke-width:2px
    style S fill:#ffdddd,stroke:#d9534f,stroke-width:2px
    style E fill:#d9edf7,stroke:#31708f,stroke-width:2px
    style M fill:#dff0d8,stroke:#3c763d,stroke-width:2px

雙精度浮點數（64位元）分為三個部分：

  1. 符號位元（1位元）： 決定正負號。
  2. 階碼/指數位元（11位元）： 加上偏移量 1023，範圍覆蓋從 $2^{-1022}$ 到 $2^{1023}$ 的極其廣闊的動態範圍。
  3. 尾數位元（52位元）： 採用科學記號法規格化表示，隱含省略最高位整數 1.，實際擁有 53位元 二進位有效數字精度（相當於十進位約15至17位精度）。
$$V = (-1)^s \times (1 + f) \times 2^{e - 1023}$$

3. 「0.1 + 0.2」的底層執行全過程

$$\text{float64}(0.1) = 0.1000000000000000055511151231257827021181583404541015625$$$$\text{float64}(0.2) = 0.200000000000000011102230246251565404236316680908203125$$

當兩個數相加時，CPU首先執行對階（Alignment Shift），將階碼較小的 0.1 尾數向右移動 1 位元，然後與 0.2 的尾數相加。 相加後的結果在第54位元發生截斷，並觸發 IEEE 754 的預設捨入模式——就近捨入到偶數（Round-to-Nearest, Ties-to-Even）。

$$\mathbf{0.3000000000000000444089209850062616169452667236328125}$$$$\text{float64}(0.3) = 0.299999999999999988897769753748434595763683319091796875$$

兩個二進位位元模式截然不同，因此 0.1 + 0.2 === 0.3 判定為 false。

4. 數值計算中的四種惡魔誤差

  flowchart TD
    subgraph ErrorTaxonomy ["數值計算的核心誤差類型"]
        R["捨入誤差 (Rounding Error)\n無限循環小數截斷產生的基本物理誤差"]
        C["災難性抵消 (Catastrophic Cancellation)\n【最凶險】相近數字相減導致高位有效數字全部歸零"]
        A["大數吃小數 (Absorption)\n大小相差懸殊時，小數值在對階右移中被全部移出暫存器"]
        T["截斷誤差 (Truncation Error)\n用有限泰勒級數近似微積分帶來的演算法誤差"]
    end

    R --> C
    R --> A
    style C fill:#ffdddd,stroke:#d9534f,stroke-width:2px
    style A fill:#fff3cd,stroke:#856404,stroke-width:2px
  1. 災難性抵消（Catastrophic Cancellation）： 當兩個極其接近的浮點數相減時，原本相同的有效高位被全部抵消，只留下充滿捨入噪聲的末尾幾位，導致計算結果的有效位數斷崖式崩塌。
  2. 大數吃小數（Absorption）： 例如在 Python 中計算 (1e16 + 1.0) - 1e16，由於 $10^{16}$ 已經佔滿了雙精度的全部有效位元，加 $1.0$ 時其尾數被完全移出53位元範圍，結果輸出 0.0。
  3. 卡漢求和演算法（Kahan Summation）： 利用一個獨立的補償變數記錄每次加法丟失的低位捨入殘差，在下一次循環中補償回來，從而實現億級數據累加的零誤差累積。

5. 改變歷史的浮點災難

  flowchart TD
    subgraph Patriot ["1991年：愛國者飛彈攔截失敗事故"]
        P1["內置計時器：每0.1秒遞增一次整數"]
        P2["0.1轉24位定點數產生 0.000000095秒微小誤差"]
        P3["連續開機運行100小時，誤差累計達 0.3433秒"]
        P4["飛毛腿飛彈以4馬赫飛來，雷達探測視窗偏移 687米\n攔截失敗致美軍營房被擊中，28人喪生"]
        P1 --> P2 --> P3 --> P4
    end

    subgraph Ariane ["1996年：亞利安5型火箭爆炸"]
        A1["水平速度參數從64位浮點數強轉為16位有符號整數"]
        A2["加速度遠高於老型號，數值超過 32767 導致溢位"]
        A3["未捕獲硬體異常導致慣導電腦同時崩潰\n火箭自毀，直接經濟損失5億美元"]
        A1 --> A2 --> A3
    end

    style Patriot fill:#fff2f0,stroke:#d9534f,stroke-width:2px
    style Ariane fill:#f0f7ff,stroke:#0275d8,stroke-width:2px
  • 海灣戰爭愛國者飛彈慘劇（1991）： 0.1秒時鐘轉換的微小截斷誤差，在連續運行100小時後累計成0.34秒的時鐘漂移。對於以4馬赫高速飛行的飛毛腿飛彈，這相當於687公尺的雷達追蹤視窗偏差，導致雷達鎖定虛空，最終28名美軍士兵犧牲。
  • 亞利安5型運載火箭首飛爆炸（1996）： 軟體將一個64位元浮點水平速度強轉為16位元整數，超過32767上限發生溢位崩潰，導致價值5億美元的火箭與衛星在空中化為火球。

6. 工程師的實踐準則

  1. 禁止直接等值比較： 嚴禁使用 a == b，必須使用機器精度 $\epsilon$（Epsilon）：
    1
2

    import math
math.isclose(a, b, rel_tol=1e-9, abs_tol=1e-12)
  2. 金融會計領域的絕對禁令： 金融系統中嚴禁使用 float。必須使用整數最小貨幣單位（分/厘）或任意精度十進位庫（Python decimal.Decimal / Java BigDecimal）。
  3. 演算法代數重構： 在二次方程求根等場景中，透過分子有理化將相近減法改寫為加法，徹底規避災難性抵消。

7. 結語：有限位元征服無限連續的工程奇蹟

0.1 + 0.2 = 0.30000000000000004 絕不是電腦的恥辱，而是人類工程學的巔峰傑作。 用區區64個微小的電荷開關，將橫跨600個數量級的浩瀚物理宇宙實數濃縮其中，並在數十億分之一秒內完成精確運算。理解這一妥協的本質，正是我們成為卓越軟體工程師的必經之路。

comments powered by Disqus