直接用 == 比较浮点数会出错，因为浮点数在内存中是二进制近似表示，0.1+0.2≠0.3等误差是IEEE 754标准下的必然现象，需用 std::abs(a - b)

为什么直接用 == 比较两个 float 或 double 会出错

浮点数在内存中是二进制近似表示的，很多十进制小数（比如 0.1）根本无法精确存储。哪怕你只是做几次加减乘除，结果也可能和“数学上相等”的值差一个极小的量——这个差值不是bug，是IEEE 754标准下的必然现象。

所以 a == b 在绝大多数浮点场景下都是危险的：它要求比特位完全一致，而实际计算路径不同、编译器优化级别不同、甚至不同CPU指令集（如x87 vs SSE）都可能导致结果微异。

• 常见错误现象：0.1 + 0.2 == 0.3 返回 false
• 使用场景：数值迭代收敛判断、单元测试断言、配置阈值比较
• 性能影响：几乎为零；但滥用大 epsilon 会掩盖真实误差

std::abs(a - b) 是最常用解法，但 <code>epsilon 怎么选

固定值 epsilon（比如 1e-6）只适用于数量级接近 1.0 的数。一旦 a 和 b 是 1e-10 或 1e6 级别，同一 epsilon 就会失效：太大会误判，太小则永远不触发。

更稳妥的做法是用相对误差 + 绝对误差组合判断，覆盖极小值和常规值：

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

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

bool nearly_equal(double a, double b, double abs_eps = 1e-12, double rel_eps = 1e-9) {
    double diff = std::abs(a - b);
    if (diff < abs_eps) return true;
    return diff < rel_eps * std::max(std::abs(a), std::abs(b));
}

• abs_eps 防止除零和极小值下相对误差爆炸（比如两个接近 0.0 的数）
• rel_eps 控制相对精度，1e-9 对 double 通常够用，float 可用 1e-5
• 不要直接用 std::numeric_limits<double>::epsilon()</double> 做比较阈值——它表示的是 1.0 附近的最小可表示差值，不是通用容差

哪些情况不能只靠 epsilon 解决

当浮点运算本身引入了不可控误差积累，或涉及特殊值时，epsilon 比较就只是第一道防线，后面还得补逻辑。

• NaN：任何与 NaN 的比较（包括 == 和 ）都返回 <code>false，必须先用 std::isnan() 检查
• 无穷大：std::isinf() 单独处理，避免 abs(inf - inf) 得到 NaN
• 跨平台一致性需求：如果代码要跑在 ARM 和 x86 上，且对中间结果精度敏感，得禁用 FMA（融合乘加）或统一用 -ffp-contract=off 编译
• 算法层面问题：比如牛顿法求根时，用 epsilon 判断收敛，但若导数接近零，迭代可能停滞在错误位置——这时需要额外检查梯度模长

单元测试里怎么写安全的浮点断言

Google Test 提供 ASSERT_NEAR 和 ASSERT_DOUBLE_EQ，但它们内部用的是固定 epsilon，对非单位量级数据不鲁棒。自己封装一层更可控。

示例（GTest 风格）：

void EXPECT_NEAR_REL(double a, double b, double rel_eps = 1e-9) {
    ASSERT_FALSE(std::isnan(a) || std::isnan(b)) << "NaN in comparison";
    double diff = std::abs(a - b);
    double scale = std::max({1.0, std::abs(a), std::abs(b)});
    EXPECT_LT(diff, rel_eps * scale) << "Expected " << a << " ~ " << b;
}

• 测试前主动过滤 NaN，避免断言崩溃或静默失败
• 把 scale 下界设为 1.0，既保留对小数的绝对容差，又不让 rel_eps 在大数上过度放宽
• 别在 CI 脚本里用 std::cout 调试——输出精度高不代表值精确，反而容易误导

真正难的从来不是写对一个 epsilon，而是搞清你的误差来源：是舍入？是算法固有？还是输入本身就不确定？后者往往该换数据结构，而不是调 epsilon。