浮点数舍入是否随机？相同浮点数舍入结果会受系统状态影响吗

严格遵循IEEE 754标准实现的浮点数舍入操作，不存在“随系统资源状态随机变化”的特性，你听到的相关说法不符合浮点数规范设计，你在C#中循环执行0.1 + 0.2始终得到固定结果0.30000000000000004，就是最直接的验证。

你观察到的迭代求解结果波动、甚至发散的现象，和“单个浮点数舍入结果随机”没有关系，常见诱因有三类：

• 激进编译优化打破精度一致性：多数Fortran编译器支持-ffast-math类性能优先的优化选项，开启后不再严格遵守IEEE 754精度要求。x86架构FPU寄存器默认是80位扩展精度，计算过程中中间值会暂存在寄存器里，如果CPU寄存器资源紧张，系统会随机把暂存的中间值刷回64位双精度内存，这个截断时机完全受当前进程调度、寄存器占用状态影响，会引入随机的微小截断误差。非线性系统的迭代求解本身对初始误差有极强的放大效应，上百步迭代后，最初1e-19量级的截断差就能累积成明显的结果偏差，碰到强混沌特性的系统直接发散是非常普遍的情况。
• 并行计算的执行顺序波动：如果计算引擎开启了OpenMP、MPI等并行能力，由于浮点运算不满足结合律，不同线程、进程的执行顺序会受系统负载影响每次发生变化，浮点累加、乘加的顺序变了，每一步的舍入节点就会变化，最终结果自然不一致。这种差异来自计算顺序的随机变化，不是单个数值的舍入规则发生了改变。
• 代码本身的内存问题：默认编译选项下Fortran不会自动做数组边界检查，要是代码存在局部数组未初始化、数组下标越界读写的问题，运行时读到的内存垃圾值完全受当前系统内存状态影响，也会导致结果随机波动，这属于代码逻辑bug，和浮点数舍入逻辑无关。

你做的对照测试场景太简单，触发不了上述的波动条件：

• 单次0.1 + 0.2计算逻辑极短，全程可以在寄存器内完成，不会出现中间值被随机刷回内存的截断操作
• 计算顺序完全固定，不存在并行调度、分支跳转带来的执行顺序变化
• 没有迭代过程的误差放大效应，就算存在极微小的精度差，也不会累积到可观测的程度

内容的提问来源于stack exchange，提问作者Mhatami