「0.1加0.2等于0.30000000000000004?！惯@不是某個實習生寫的爛代碼，是IEEE 754浮點標準（二進制浮點數(shù)算術標準）在JavaScript、Python、Java里跑了半個世紀的"正確"結(jié)果。

一位谷歌工程師最近在技術博客復盤分數(shù)運算時，把這個問題重新拽回開發(fā)者視野。他說得很直接：浮點數(shù)的精度陷阱，本質(zhì)上是我們用十進制的大腦去猜二進制的心思，猜錯了。

1960年代的遺產(chǎn)：為什么0.1在電腦里是無限循環(huán)小數(shù)

故事要從1960年代說起。當時計算機科學家面臨一個選擇：用二進制表示小數(shù)，還是用十進制？二進制贏了，因為硬件實現(xiàn)更快、更省硅片。

但代價是隱形的。十進制的0.1，換成二進制是0.0001100110011...無限循環(huán)。IEEE 754標準只能存64位，剩下的尾巴被砍掉。單次誤差小到10^-16級別，但疊加幾千次，財務系統(tǒng)里的 penny 就開始莫名其妙消失。

2008年，歐洲航天局阿麗亞娜5號火箭發(fā)射37秒后自毀，2億美元炸成煙花。事后調(diào)查發(fā)現(xiàn)，一個64位浮點數(shù)被塞進16位整數(shù)，溢出報錯。導航系統(tǒng)判定"出錯了"，觸發(fā)自毀程序。這不是分數(shù)運算的鍋，但屬于同一類問題：人類以為"差不多就行"，機器較真起來要命。

分數(shù)運算的古老規(guī)則，恰恰能避開這個坑。1/3加1/3加1/3，浮點數(shù)給你0.999999...，分數(shù)直接等于1。沒有近似，沒有累積誤差。

分數(shù)運算的三條鐵律：為什么通分比乘法更燒腦

加減法最折騰。3/7加5/11，你不能直接分子加分子、分母加分母。必須先找公分母，把兩塊不同大小的"披薩切片"切成同樣大小。

最笨的辦法：7乘11得77，分子變成33加35，結(jié)果68/77。但4/6加1/4，分母直接相乘得24，其實最小公倍數(shù)（LCD）是12。用LCD計算，中間數(shù)字更小，溢出風險更低。

乘法反而最簡單。分子乘分子，分母乘分母，3/7乘5/11直接得15/77。除法就是乘以倒數(shù)，把第二個分數(shù)上下翻轉(zhuǎn)。

每次運算完必須約分。24/36的最大公約數(shù)（GCD）是12，約成2/3。谷歌工程師在博客里貼了一段歐幾里得算法的JavaScript實現(xiàn)，十行代碼，跑了兩千年。

帶分數(shù)是人類的妥協(xié)，假分數(shù)是機器的母語。2又3/4寫成11/4，運算時少一層轉(zhuǎn)換。輸出時再換回帶分數(shù)，用戶看著舒服。

現(xiàn)代編程語言的分裂：誰還在用分數(shù)算錢

Python有fractions模塊，Java有BigDecimal，C#用decimal類型。這些都不是默認選項，得開發(fā)者主動想起來用。

金融領域早就學乖了。彭博終端、交易所核心系統(tǒng)，要么用定點數(shù)（fixed-point），要么直接用整數(shù)存"分"而不是"元"。1.23美元存成123，徹底避開浮點。

但科學計算和圖形渲染不一樣。物理模擬要速度，GPU用FP16、FP32滿天飛。誤差？每幀重新算，上一幀的偏差不累積。游戲畫面抖動一幀，玩家看不出來；銀行賬戶少一分錢，客服電話被打爆。

谷歌工程師的觀察是：分數(shù)運算在"需要精確"和"需要速度"的夾縫里存活。有理數(shù)庫（rational number library）存在，但調(diào)用成本比原生浮點高一個數(shù)量級。大多數(shù)開發(fā)者選擇"先跑起來，精度問題以后再說"——然后永遠沒以后。

一個木工師傅的啟示：為什么手工測量比CAD更準

文章結(jié)尾，作者講了一個場景。木工做柜子，CAD圖紙標了0.3333英尺，師傅直接拿尺子找1/3標記。十進制是給人看的，分數(shù)是給活干的。

編程同理。0.1+0.2的笑話流傳二十年，不是沒人想修，是修的成本比忍的成本更高。IEEE 754已成硬件標準，全世界CPU都認。要改？等于讓所有人換一把尺子。

但分數(shù)運算的知識沒有過時。2023年Stack Overflow調(diào)研顯示，"浮點數(shù)精度問題"仍是開發(fā)者搜索的前50話題之一，年搜索量超47萬次。每個搜這個問題的人，都在重新發(fā)現(xiàn)1960年代那個被砍掉的無限循環(huán)尾巴。