C++浮点数比较的终极方案：为什么fabs(a-b)＜eps不总是有效？-CSDN博客

C++浮点数比较的终极方案：为什么fabs(a-b)<eps不总是有效？

在图形渲染中，一个像素的偏移可能导致模型撕裂；在科学计算里，微小的误差累积会让仿真结果谬以千里。对于每一位与C++浮点数打交道的开发者而言，那句经典的 if (fabs(a - b) < eps) 几乎是刻在DNA里的条件判断。它简单、直观，仿佛一把万能钥匙，能解开所有关于“相等”的困惑。然而，当你满怀信心地将它应用于复杂的物理引擎或金融模型时，却可能遭遇一些难以解释的“幽灵”bug——计算结果在理论上应该收敛，却意外地振荡；本该相等的值，判断却失败了。

问题不在于这条语句本身是错的，而在于我们常常把它当作一个绝对真理来使用，却忽略了浮点数运算本身是一个充满妥协与近似的世界。eps（epsilon）这个“无穷小量”的选取，并非一个放之四海而皆准的魔法常数。在不同的运算上下文、不同的数量级、甚至不同的硬件平台上，一个固定的 eps 值可能会从守护神变成捣蛋鬼。本文将带你深入浮点数的幽微之处，拆解 fabs(a-b)<eps 失效的典型场景，并构建一套更具弹性、更贴合实战的浮点数比较策略。

1. 浮点数不是实数：理解误差的根源

在深入解决方案之前，我们必须从根本上接受一个事实：计算机中的 float 和 double 类型，并非数学意义上完美的实数。它们是有限精度的二进制浮点近似。这种近似遵循IEEE 754标准，但正是这种标准化下的有限表示，带来了不可避免的误差。

1.1 表示误差与舍入误差

想象一下用十进制小数精确表示 1/3，你会得到 0.333333...，永远写不完。计算机用二进制也存在同样的问题。很多在十进制下看起来“整洁”的数，比如 0.1，在二进制下是一个无限循环小数。当它被存储到有限的 double（通常是64位）中时，就必须进行舍入。

#include <iostream>
#include <iomanip>

int main() {
    double a = 0.1;
    std::cout << std::setprecision(20) << a << std::endl;
    // 输出可能是：0.10000000000000000555
}

这多出来的 0.00000000000000000555 就是表示误差。它是数值在存储那一刻就注定携带的“原罪”。

更复杂的是舍入误差。每一次浮点数运算（加、减、乘、除，甚至开方、三角函数），结果都可能需要舍入到最接近的可表示值。多次运算会导致误差累积和传播。

double x = 0.0;
for (int i = 0; i < 10; ++i) {
    x += 0.1;
}
double y = 1.0;
std::cout << (x == y) << std::endl; // 很可能输出 0 (false)
std::cout << std::setprecision(20) << "x = " << x << ", y = " << y << std::endl;
// x 可能等于 0.99999999999999988898

1.2 为什么简单的 `eps` 比较会失效？

fabs(a - b) < eps 的核心思想是：如果两个数的绝对差值小于一个非常小的阈值，我们就认为它们“足够接近”从而相等。这被称为绝对误差比较。

它的失效场景非常典型：

数量级差异：对于极大或极小的数，固定的 eps 可能失去意义。例如，比较 1e-20 和 2e-20，绝对差是 1e-20。如果你设置的 eps=1e-10，这个差远小于 eps，判断为“相等”。但从相对角度看，它们相差了一倍！反之，比较 1e10 和 1e10 + 1，绝对差是1，远大于 1e-10，判断为“不等”，但1相对于 1e10 的误差只有 1e-10，在许多工程场景下可以接受。
运算路径依赖：计算 sin(π)，理论上结果是0。但由于 M_PI 本身是π的近似值，sin(M_PI) 会得到一个接近0但非零的小数。这个误差的大小不仅取决于 sin 函数的实现精度，还取决于 M_PI 的精度。此时，eps 应该设多大？1e-10？1e-12？这变得不确定。
病态问题与误差放大：在数值计算中，有些问题对输入误差极其敏感。例如，计算两个接近相等的超大数的差值（“大数吃小数”），或者求解近乎奇异的线性方程组。在这种情况下，初始微小的