起初是在一个春晚魔术《惊喜定格》的解密视频下面有人贴出了小米计算器的问题：
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
