比较浮点数取决于上下文。因为即使改变操作的顺序也会产生不同的结果，所以知道你希望这些数字有多“相等”是很重要的。

在研究浮点数比较时，比较Bruce Dawson编写的浮点数是一个很好的开始。

以下定义来自Knuth的《The art of computer programming》:

bool approximatelyEqual(float a, float b, float epsilon)
{
    return fabs(a - b) <= ( (fabs(a) < fabs(b) ? fabs(b) : fabs(a)) * epsilon);
}

bool essentiallyEqual(float a, float b, float epsilon)
{
    return fabs(a - b) <= ( (fabs(a) > fabs(b) ? fabs(b) : fabs(a)) * epsilon);
}

bool definitelyGreaterThan(float a, float b, float epsilon)
{
    return (a - b) > ( (fabs(a) < fabs(b) ? fabs(b) : fabs(a)) * epsilon);
}

bool definitelyLessThan(float a, float b, float epsilon)
{
    return (b - a) > ( (fabs(a) < fabs(b) ? fabs(b) : fabs(a)) * epsilon);
}

当然，选择取决于上下文，并决定你想要的数字有多相等。

比较浮点数的另一种方法是查看数字的ULP(最后位置的单位)。虽然没有专门处理比较，但“每个计算机科学家都应该知道浮点数”这篇论文是了解浮点数如何工作以及陷阱是什么，包括什么是ULP的很好的资源。

General-purpose comparison of floating-point numbers is generally meaningless. How to compare really depends on a problem at hand. In many problems, numbers are sufficiently discretized to allow comparing them within a given tolerance. Unfortunately, there are just as many problems, where such trick doesn't really work. For one example, consider working with a Heaviside (step) function of a number in question (digital stock options come to mind) when your observations are very close to the barrier. Performing tolerance-based comparison wouldn't do much good, as it would effectively shift the issue from the original barrier to two new ones. Again, there is no general-purpose solution for such problems and the particular solution might require going as far as changing the numerical method in order to achieve stability.

你写的代码有bug:

return (diff < EPSILON) && (-diff > EPSILON);

正确的代码应该是:

return (diff < EPSILON) && (diff > -EPSILON);

(…是的，这是不同的)

我想知道晶圆厂是否会让你在某些情况下失去懒惰的评价。我会说这取决于编译器。你可能想两种都试试。如果它们在平均水平上是相等的，则采用晶圆厂实现。

如果你有一些关于两个浮点数中哪一个比另一个更大的信息，你可以根据比较的顺序来更好地利用惰性求值。

最后，通过内联这个函数可能会得到更好的结果。不过不太可能有太大改善……

编辑:OJ，谢谢你纠正你的代码。我相应地删除了我的评论

使用任何其他建议都要非常小心。这完全取决于上下文。

我花了很长时间在一个系统中追踪错误，该系统假设|a-b|<epsilon，则a==b。潜在的问题是:

The implicit presumption in an algorithm that if a==b and b==c then a==c. Using the same epsilon for lines measured in inches and lines measured in mils (.001 inch). That is a==b but 1000a!=1000b. (This is why AlmostEqual2sComplement asks for the epsilon or max ULPS). The use of the same epsilon for both the cosine of angles and the length of lines! Using such a compare function to sort items in a collection. (In this case using the builtin C++ operator == for doubles produced correct results.)

就像我说的，这完全取决于上下文和a和b的预期大小。

顺便说一下，std::numeric_limits<double>::epsilon()是“机器epsilon”。它是1.0和下一个用double表示的值之间的差值。我猜它可以用在比较函数中，但只有当期望值小于1时。(这是对@cdv的回答的回应…)

同样，如果你的int算术是双精度的(这里我们在某些情况下使用双精度来保存int值)，你的算术是正确的。例如，4.0/2.0将等同于1.0+1.0。只要你不做导致分数(4.0/3.0)的事情，或者不超出int的大小。

我的课程是基于之前发布的答案。非常类似于谷歌的代码，但我使用了一个偏差，将所有NaN值推到0xFF000000以上。这样可以更快地检查NaN。

这段代码是为了演示概念，而不是通用的解决方案。谷歌的代码已经展示了如何计算所有平台特定的值，我不想复制所有这些。我对这段代码做了有限的测试。

typedef unsigned int   U32;
//  Float           Memory          Bias (unsigned)
//  -----           ------          ---------------
//   NaN            0xFFFFFFFF      0xFF800001
//   NaN            0xFF800001      0xFFFFFFFF
//  -Infinity       0xFF800000      0x00000000 ---
//  -3.40282e+038   0xFF7FFFFF      0x00000001    |
//  -1.40130e-045   0x80000001      0x7F7FFFFF    |
//  -0.0            0x80000000      0x7F800000    |--- Valid <= 0xFF000000.
//   0.0            0x00000000      0x7F800000    |    NaN > 0xFF000000
//   1.40130e-045   0x00000001      0x7F800001    |
//   3.40282e+038   0x7F7FFFFF      0xFEFFFFFF    |
//   Infinity       0x7F800000      0xFF000000 ---
//   NaN            0x7F800001      0xFF000001
//   NaN            0x7FFFFFFF      0xFF7FFFFF
//
//   Either value of NaN returns false.
//   -Infinity and +Infinity are not "close".
//   -0 and +0 are equal.
//
class CompareFloat{
public:
    union{
        float     m_f32;
        U32       m_u32;
    };
    static bool   CompareFloat::IsClose( float A, float B, U32 unitsDelta = 4 )
                  {
                      U32    a = CompareFloat::GetBiased( A );
                      U32    b = CompareFloat::GetBiased( B );

                      if ( (a > 0xFF000000) || (b > 0xFF000000) )
                      {
                          return( false );
                      }
                      return( (static_cast<U32>(abs( a - b ))) < unitsDelta );
                  }
    protected:
    static U32    CompareFloat::GetBiased( float f )
                  {
                      U32    r = ((CompareFloat*)&f)->m_u32;

                      if ( r & 0x80000000 )
                      {
                          return( ~r - 0x007FFFFF );
                      }
                      return( r + 0x7F800000 );
                  }
};

我使用这个代码。不像上面的答案，这允许一个人 给出一个在代码注释中解释的abs_relative_error。

第一个版本比较复数，使错误 可以用两个矢量之间的夹角来解释 在复平面上具有相同的长度(这给出了一点 洞察力)。然后是2实数的正确公式 数字。

https://github.com/CarloWood/ai-utils/blob/master/almost_equal.h

后者是

template<class T>
typename std::enable_if<std::is_floating_point<T>::value, bool>::type
   almost_equal(T x, T y, T const abs_relative_error)
{
  return 2 * std::abs(x - y) <= abs_relative_error * std::abs(x + y);
}

其中abs_relative_error基本上(两倍)是文献中最接近定义的绝对值:相对错误。但这只是名字的选择。

我认为在复平面中最明显的是。如果|x| = 1, y在x周围形成一个直径为abs_relative_error的圆，则认为两者相等。