起初是在一個春晚魔術《驚喜定格》的解密視頻下面有人貼出了小米計算器的問題：
1÷(1-1) = ∞；
1÷0=不能除以0
左右計算結果不同
我們做了幾組測試，結果如下：
幾組測試用例結果
黑盒測試的結果很明顯：只要除數是通過函數或表達式計算爲 0 的，結果就顯示爲 ∞。
顯示爲∞的原理
在確認問題之前，先來了解爲什麼會出現∞
在小米計算器的除法邏輯中，如果除數一開始就是確切的 0，則輸出“不能除以 0”。
其他情況則走實數計算路徑，底層使用的是 CR 庫
此處不討論有理數分支情況
反編譯代碼定位
在 CR 的實數計算中，如果除數爲 0，會拋出 PrecisionOverflowException 錯誤。
計算器將該錯誤統一處理爲 infinity（無窮大），再經過上層展示爲 ∞。
不過小米應該對 com.hp.creals.CR 做過修改，因爲原 CR 文檔中拋出的錯誤是 PrecisionOverflowError，而小米使用的是 PrecisionOverflowException。
反編譯代碼定位
程序爲什麼要這樣做？
顯示爲 ∞ 是工程思維的體現。
我們不妨先拋開 CR 庫，以更常見的浮點數標準 IEEE 754 爲例來理解。(需要說明的是，小米計算器在此處並非直接使用 IEEE 754，但其工程思維是相通的。)
a / 0 = INF（a 爲非 0 實數）
INF - INF = NaN
INF表示無窮大
NaN表示未定義
在 IEEE 754 下，不僅 a / 0 的結果是 INF，INF 和 NaN 還可以繼續參與運算
這種設計保證了計算過程的連貫性，避免處處都需要判斷除數是否爲 0。
而且因爲 INF 和 NaN 都可以參加後續運算（是的，INF也能加減乘除），這使得計算結果可以傳遞到最終數據上
因爲 INF 和 NaN 可以傳遞到最終結果，研究人員一看便知哪組數據出了問題，既可選擇忽略，也可回溯定位。
關鍵在於，整個系統運算速度快、代碼健壯，沒有堆積如山的 if 分支，也避免了因除 0 異常捕捉不到位而導致的崩潰。
除以 0 得到 ∞ 的實際應用
試想一下，一個用於氣象模擬系統，運算規模高達數億次。
開發人員不可能爲每一個潛在的除法運算都預先判斷除數是否爲零——因爲除數本身往往是複雜表達式的結果，靜態分析幾乎不可能全覆蓋。
如果某一時刻，在一系列浮點運算後恰好出現除數爲 0，系統若因此拋出異常或中斷，可能導致長達數小時的計算前功盡棄。
此處僅爲說明工程思維的動機，不代表實際就是這麼做
因此，在工程實踐中，讓計算“能繼續下去”，並讓異常結果（如 ∞ 或 NaN）在最終數據中保留和傳遞，往往比“嚴格遵循數學定義而中斷計算”更具實際意義。
研究人員可以事後根據結果中的 ∞ 或 NaN 回溯問題，而不必承擔計算中斷的代價。
計算器顯示爲 ∞ 是否合理？
從普通用戶和數學嚴謹性角度看，這樣顯示不合理。
在實數體系中，除以 0 是未定義的。顯示爲 ∞ 既不符合數學認知，也容易導致推理上的混亂
但從工程思維角度看，問題更爲複雜。IEEE 754 的設計之所以被認爲是工程上的典範，不僅在於它定義了 a/0 = ∞，更在於它完整定義了 ∞ 和 NaN 的後續運算規則（如 ∞/∞ = NaN），形成一個自洽的體系。
而小米計算器的做法是：在除零時輸出 ∞，但當 ∞ 參與後續運算（如 ∞/∞）時，卻沒有遵循這一規則——實際測試結果顯示仍爲 ∞，而非 NaN。（如下圖）
這個結果令人詫異
這意味着小米計算器只借用了“∞”的符號，卻沒有完整實現工程思維背後的運算體系。這種“半工程思維”的設計，既無法在數學上自圓其說，也無法在工程上真正發揮 ∞ 和 NaN 的價值（如讓異常結果傳遞、便於回溯定位）。
因此，小米計算器的這一設計，無論從數學嚴謹性還是工程完整性來看，都難稱合理。
參考資料（#替換爲.)
The constructive reals as a Java library
www#sciencedirect#com/science/article/pii/S1567832604000736
com.hp.creals.CR
www#hboehm#info/new_crcalc/com/hp/creals/CR.html
IEEE 754
ieeexplore#ieee#org/document/8766229
文末藏個小知識：
js完全遵循IEEE 754規範，所以在瀏覽器 F12 控制檯裏
輸入 1/0 會得到 Infinity
輸入 0/0 會得到 NaN
輸入 (1/0)/(1/0) 會得到 NaN
更多遊戲資訊請關註：電玩幫遊戲資訊專區
電玩幫圖文攻略 www.vgover.com
