First of all, floating point values are not "random" in their behavior. Exact comparison can and does make sense in plenty of real-world usages. But if you're going to use floating point you need to be aware of how it works. Erring on the side of assuming floating point works like real numbers will get you code that quickly breaks. Erring on the side of assuming floating point results have large random fuzz associated with them (like most of the answers here suggest) will get you code that appears to work at first but ends up having large-magnitude errors and broken corner cases.

首先，如果你想用浮点数编程，你应该读一下:

每个计算机科学家都应该知道浮点运算

是的，通读一遍。如果这对你来说负担太大，你应该使用整数/固定点来计算，直到你有时间阅读它。: -)

现在，说了这么多，精确浮点比较的最大问题归结为:

The fact that lots of values you may write in the source, or read in with scanf or strtod, do not exist as floating point values and get silently converted to the nearest approximation. This is what demon9733's answer was talking about. The fact that many results get rounded due to not having enough precision to represent the actual result. An easy example where you can see this is adding x = 0x1fffffe and y = 1 as floats. Here, x has 24 bits of precision in the mantissa (ok) and y has just 1 bit, but when you add them, their bits are not in overlapping places, and the result would need 25 bits of precision. Instead, it gets rounded (to 0x2000000 in the default rounding mode). The fact that many results get rounded due to needing infinitely many places for the correct value. This includes both rational results like 1/3 (which you're familiar with from decimal where it takes infinitely many places) but also 1/10 (which also takes infinitely many places in binary, since 5 is not a power of 2), as well as irrational results like the square root of anything that's not a perfect square. Double rounding. On some systems (particularly x86), floating point expressions are evaluated in higher precision than their nominal types. This means that when one of the above types of rounding happens, you'll get two rounding steps, first a rounding of the result to the higher-precision type, then a rounding to the final type. As an example, consider what happens in decimal if you round 1.49 to an integer (1), versus what happens if you first round it to one decimal place (1.5) then round that result to an integer (2). This is actually one of the nastiest areas to deal with in floating point, since the behaviour of the compiler (especially for buggy, non-conforming compilers like GCC) is unpredictable. Transcendental functions (trig, exp, log, etc.) are not specified to have correctly rounded results; the result is just specified to be correct within one unit in the last place of precision (usually referred to as 1ulp).

When you're writing floating point code, you need to keep in mind what you're doing with the numbers that could cause the results to be inexact, and make comparisons accordingly. Often times it will make sense to compare with an "epsilon", but that epsilon should be based on the magnitude of the numbers you are comparing, not an absolute constant. (In cases where an absolute constant epsilon would work, that's strongly indicative that fixed point, not floating point, is the right tool for the job!)

编辑:特别地，相对大小的检查应该看起来像这样:

if (fabs(x-y) < K * FLT_EPSILON * fabs(x+y))

FLT_EPSILON是float.h中的常量(将其替换为双精度的DBL_EPSILON或长双精度的LDBL_EPSILON)， K是你选择的常量，这样你的计算的累积误差在最后一个地方肯定是由K个单位限制的(如果你不确定你得到的误差范围计算是正确的，让K比你的计算说的应该大几倍)。

最后，请注意，如果使用此方法，可能需要在接近零时进行一些特殊处理，因为FLT_EPSILON对于非法线没有意义。一个快速的解决方法是:

if (fabs(x-y) < K * FLT_EPSILON * fabs(x+y) || fabs(x-y) < FLT_MIN)

如果使用double，同样替换DBL_MIN。

The last time I checked the C standard, there was no requirement for floating point operations on doubles (64 bits total, 53 bit mantissa) to be accurate to more than that precision. However, some hardware might do the operations in registers of greater precision, and the requirement was interpreted to mean no requirement to clear lower order bits (beyond the precision of the numbers being loaded into the registers). So you could get unexpected results of comparisons like this depending on what was left over in the registers from whoever slept there last.

也就是说，尽管我一看到它就努力删除它，但我工作的机构有大量使用gcc编译并运行在linux上的C代码，我们已经很长时间没有注意到这些意想不到的结果了。我不知道这是否是因为gcc为我们清除了低阶位，80位寄存器在现代计算机上不用于这些操作，标准已经改变了，还是什么。我想知道是否有人可以引用章节和诗句。

我使用下面的比较函数来比较小数点后的数位:

bool compare(const double value1, const double value2, const int precision)
{
    int64_t magnitude = static_cast<int64_t>(std::pow(10, precision));
    int64_t intValue1 = static_cast<int64_t>(value1 * magnitude);
    int64_t intValue2 = static_cast<int64_t>(value2 * magnitude);
    return intValue1 == intValue2;
}

// Compare 9 decimal places:
if (compare(theView.frame.origin.x, 0, 9)) {
    // do important operation
}

另一个可能需要记住的问题是，不同的实现做事情的方式不同。我非常熟悉的一个例子是索尼Playstation 2上的FP单元。与任何X86设备中的IEEE FP硬件相比，它们有显著的差异。引用的文章提到完全缺乏对inf和NaN的支持，而且情况变得更糟。

不太为人所知的是我后来所知道的“一位乘法”错误。对于float x的特定值:

    y = x * 1.0;
    assert(y == x);

断言将失败。在一般情况下，有时，但不总是，在Playstation 2上FP相乘的结果比等效的IEEE尾数少一位。

我的观点是，您不应该假设将FP代码从一个平台移植到另一个平台会产生相同的结果。任何给定的平台都是内部一致的，因为结果在该平台上不会改变，只是它们可能与另一个平台不一致。例如，X86上的CPython使用64位双精度来表示浮点数，而Cortex MO上的CircuitPython必须使用软件FP，并且只使用32位浮点数。不用说，这会引起差异。

我40多年前学到的一句话今天依然适用。“在计算机上做浮点运算就像移动一堆沙子。每次你做任何事，都会留下一点沙子，捡起一点泥土。”

Playstation是索尼公司的注册商标。

因为0完全可以表示为一个IEEE754浮点数(或者使用我曾经使用过的任何其他f-p数字实现)，与0比较可能是安全的。然而，如果你的程序计算了一个值(比如theView.frame.origin.x)，你有理由相信它应该是0，但你的计算不能保证它是0，你可能会被咬。

为了澄清一点，计算如下:

areal = 0.0

会(除非你的语言或系统坏了)创建一个值(areal==0.0)返回true，但另一个计算，如

areal = 1.386 - 2.1*(0.66)

可能不会。

如果你能保证你的计算产生的值是0(而不仅仅是它们产生的值应该是0)，那么你可以继续将f-p值与0进行比较。如果你不能保证自己达到要求的程度，最好坚持通常的“宽容平等”方法。

在最坏的情况下，不小心比较f-p值可能是极其危险的:想想航空电子设备、武器制导、发电厂操作、车辆导航，几乎所有计算与现实世界相结合的应用。

对《愤怒的小鸟》来说，没有那么危险。

与0比较是安全的操作，只要0不是一个计算值(如上面的回答所述)。这样做的原因是0在浮点数中是一个完全可表示的数字。

谈到完全可表示的值，您可以在2的幂概念中获得24位范围(单精度)。所以12 4是完全可表示的，。5。25和。125也是。只要你所有重要的比特都是24比特的，你就是黄金。所以10.625可以被精确地表示出来。

这很好，但在压力下很快就会崩溃。我脑海中浮现出两种场景: 1)当涉及到计算时。不要相信√(3)*√(3)== 3。只是不会是那样的。它可能不会在一个范围内，就像其他答案暗示的那样。 2)当涉及任何非2的幂(NPOT)时。所以这听起来可能很奇怪，但是0.1是二进制的无限级数，因此任何涉及这样一个数字的计算从一开始就不精确。

(哦，原来的问题提到了与零的比较。不要忘记-0.0也是一个完全有效的浮点值。)