Python 浮点数误差的根本来源解析

这是正常现象而非 bug，因十进制 0.1 在二进制中为无限循环小数，ieee 754 双精度浮点数截断导致精度损失，故 0.1 + 0.2 ≠ 0.3；应避免用 == 比较浮点数，改用 abs(a – b)

为什么 0.1 + 0.2 != 0.3 是正常现象，不是 bug

这不是 python 的问题，而是所有用二进制表示浮点数的系统共有的限制。十进制小数 0.1 在二进制中是无限循环小数（类似十进制里 1/3 = 0.333...），而 IEEE 754 双精度浮点数只能存约 17 位有效十进制数字，截断后必然有误差。

常见错误现象：0.1 + 0.2 == 0.3 返回 False；循环累加 0.1 十次结果不是精确 1.0；用 == 直接比较两个计算得到的浮点数失败。

• 别用 == 比较浮点数是否“相等”，改用 abs(a - b) 或 <code>math.isclose(a, b)
• math.isclose() 默认 rel_tol=1e-09，适合大多数场景；若需更高精度或处理极小值，显式传入 abs_tol
• 涉及金额、计数等必须精确的场景，直接用 decimal.Decimal，但注意它不兼容 numpy / pandas 原生运算

什么时候该用 decimal.Decimal 而不是 Float

当数值语义要求“按十进制笔算规则”时，比如财务计算、配置文件里的精度声明、测试断言中的预期值校验。

使用场景：Decimal('0.1') + Decimal('0.2') == Decimal('0.3') 恒成立；读取 json/YAML 中带小数的配置项并做精确阈值判断；生成测试用例时避免随机漂移。

立即学习“Python免费学习笔记（深入）”；

• 务必用字符串初始化：Decimal('0.1')，而不是 Decimal(0.1)——后者会先让 0.1 经历 float 误差再转
• Decimal 运算比 float 慢一个数量级以上，别在热路径（如内层循环、高频数学库）里无脑替换
• 和 numpy 交互时需注意：np.Array([Decimal('1.0')]) 会退化为 Object 数组，失去向量化优势

numpy.float64 和 Python 原生 float 的误差表现一样吗

一样。NumPy 的 float64 就是 C 语言 double 的封装，底层遵循 IEEE 754，和 Python float 共享同一套二进制表示逻辑和舍入行为。

常见错误现象：用 np.arange(0, 1, 0.1) 生成 0–1 区间序列，结果长度不是 10；np.sum([0.1] * 10) ≠ 1.0；np.unique() 把本应相等的浮点数当成不同值。

• np.arange 对步长敏感，改用 np.linspace(0, 1, 11) 更可靠（指定端点+数量，而非步长）
• 对数组做去重或分组前，先用 np.round(arr, decimals=10) 截断无效精度，再转 int 或字符串辅助判等
• 避免在 np.where 或布尔索引中直接写 arr == 0.1，换成 np.isclose(arr, 0.1)

调试浮点误差时最该看的三个地方

浮点问题往往不是单点出错，而是误差在链式计算中累积、放大，最终在某个输出环节暴露。定位时优先检查这三处。

• 输入源：从文件、网络、用户输入拿到的数字是否已被转成 float？比如 float('0.1') 立刻引入误差，应保留字符串或改用 Decimal
• 中间聚合：累加、求平均、归一化等操作是否反复用 +=？考虑用 math.fsum() 替代内置 sum()，它对浮点求和做了误差补偿
• 输出比较：日志打印、单元测试 assert、if 判断里是否用了裸 ==？只要涉及“是否等于某值”，默认走 math.isclose 更安全

真正难缠的不是单个浮点数不准，而是不同路径产生的误差不一致——比如一个用 fsum 算的总和，另一个用普通循环累加，两者在理论上应相等，实际却差了 1e-16。这种差异在分布式环境或跨平台运行时更容易浮现。