浮点数的陷阱是它们看起来像十进制，但它们是二进制的。

2的唯一素因子是2，而10的素因子为2和5。这样做的结果是，每一个可以完全写成二进制分数的数字也可以完全写成十进制分数，但只有一部分可以写成十进制分数的数字可以写成二进制分数。

浮点数本质上是一个有效位数有限的二进制分数。如果你超过这些有效数字，那么结果将被四舍五入。

当您在代码中键入文字或调用函数将浮点数解析为字符串时，它需要一个十进制数，并将该十进制数的二进制近似值存储在变量中。

当您打印浮点数或调用函数将浮点数转换为字符串时，它将打印浮点数的十进制近似值。可以将二进制数字精确地转换为十进制，但在转换为字符串*时，我所知道的任何语言都不会默认这样做。一些语言使用固定数量的有效数字，其他语言使用最短的字符串，该字符串将“往返”返回到相同的浮点值。

*Python在将浮点数转换为“decimal.decimal”时确实会进行精确的转换。这是我所知道的获得浮点数的精确十进制等效值的最简单方法。

二进制浮点数学是这样的。在大多数编程语言中，它基于IEEE 754标准。问题的关键在于，数字以这种格式表示为整数乘以2的幂；分母不是2的幂的有理数（如0.1，即1/10）无法精确表示。

对于标准binary64格式的0.1，表示形式可以完全写为

0.1000000000000000055511151231257827021181583404541015625（十进制），或0x1.999999999999ap-4，采用C99六进制浮点数表示法。

相比之下，有理数0.1（1/10）可以完全写成

0.1（十进制），或0x1.999999999999999…p-4，类似于C99十六进制浮点数，其中。。。表示9的无限序列。

程序中的常数0.2和0.3也将近似于其真实值。恰好最接近0.2的两倍大于有理数0.2，但最接近0.3的两倍小于有理数0.3。0.1和0.2的和最终大于有理数0.3，因此与代码中的常数不一致。

浮点运算问题的一个相当全面的处理是每个计算机科学家都应该知道的浮点运算。有关更容易理解的解释，请参阅floatingpoint-gui.de。

边注：所有位置（以N为基数）数字系统都有精度问题

普通的十进制（以10为基数）数字也有同样的问题，这就是为什么像1/3这样的数字最终会变成0.33333333。。。

您刚刚偶然发现了一个数字（3/10），它很容易用十进制表示，但不适合二进制。它也是双向的（在某种程度上）：1/16在十进制中是一个丑陋的数字（0.0625），但在二进制中，它看起来和十进制中的第10000个一样整洁（0.0001）**-如果我们在日常生活中习惯使用基数为2的数字系统，你甚至会看着这个数字，本能地理解你可以通过将某个数字减半，一次又一次地减半来达到这个目的。

当然，这并不是浮点数在内存中的存储方式（它们使用了一种科学的表示法）。然而，它确实说明了一点，二进制浮点精度错误往往会出现，因为我们通常感兴趣的“真实世界”数字往往是十的幂，但这只是因为我们每天使用十进制数字系统。这也是为什么我们会说71%而不是“每7取5”（71%是一个近似值，因为5/7不能用任何小数精确表示）。

所以不：二进制浮点数并没有被破坏，它们只是碰巧和其他N进制一样不完美：）

边注：在编程中使用浮点

实际上，这种精度问题意味着在显示浮点数之前，需要使用舍入函数将浮点数舍入到您感兴趣的小数位数。

您还需要用允许一定公差的比较来替换相等测试，这意味着：

如果（x==y）｛…｝则不执行

相反，如果（abs（x-y）<myToleranceValue）｛…｝，则执行此操作。

其中abs是绝对值。需要为您的特定应用程序选择myToleranceValue，这与您准备允许多少“摆动空间”以及您将要比较的最大值（由于精度损失问题）有很大关系。当心您选择的语言中的“epsilon”样式常量。这些值可以用作公差值，但它们的有效性取决于您使用的数字的大小，因为使用大数字的计算可能会超过epsilon阈值。

为了好玩，我按照标准C99的定义玩了浮点数的表示，并编写了下面的代码。

代码以3个独立的组打印浮点的二进制表示

SIGN EXPONENT FRACTION

然后，它打印一个和，当以足够的精度求和时，它将显示硬件中真正存在的值。

因此，当你写float x=999…时，编译器会将该数字转换为函数xx打印的位表示，这样函数yy打印的和就等于给定的数字。

事实上，这个总数只是一个近似值。对于数字999999999，编译器将在浮点的位表示中插入数字1000000000

代码之后，我附加了一个控制台会话，在该会话中，我计算硬件中真正存在的两个常量（减去PI和999999999）的项和，并由编译器插入其中。

#include <stdio.h>
#include <limits.h>

void
xx(float *x)
{
    unsigned char i = sizeof(*x)*CHAR_BIT-1;
    do {
        switch (i) {
        case 31:
             printf("sign:");
             break;
        case 30:
             printf("exponent:");
             break;
        case 23:
             printf("fraction:");
             break;

        }
        char b=(*(unsigned long long*)x&((unsigned long long)1<<i))!=0;
        printf("%d ", b);
    } while (i--);
    printf("\n");
}

void
yy(float a)
{
    int sign=!(*(unsigned long long*)&a&((unsigned long long)1<<31));
    int fraction = ((1<<23)-1)&(*(int*)&a);
    int exponent = (255&((*(int*)&a)>>23))-127;

    printf(sign?"positive" " ( 1+":"negative" " ( 1+");
    unsigned int i = 1<<22;
    unsigned int j = 1;
    do {
        char b=(fraction&i)!=0;
        b&&(printf("1/(%d) %c", 1<<j, (fraction&(i-1))?'+':')' ), 0);
    } while (j++, i>>=1);

    printf("*2^%d", exponent);
    printf("\n");
}

void
main()
{
    float x=-3.14;
    float y=999999999;
    printf("%lu\n", sizeof(x));
    xx(&x);
    xx(&y);
    yy(x);
    yy(y);
}

这里是一个控制台会话，我在其中计算硬件中存在的浮点值的实际值。我使用bc打印主程序输出的项的总和。可以将该和插入python-repl或类似的内容中。

-- .../terra1/stub
@ qemacs f.c
-- .../terra1/stub
@ gcc f.c
-- .../terra1/stub
@ ./a.out
sign:1 exponent:1 0 0 0 0 0 0 fraction:0 1 0 0 1 0 0 0 1 1 1 1 0 1 0 1 1 1 0 0 0 0 1 1
sign:0 exponent:1 0 0 1 1 1 0 fraction:0 1 1 0 1 1 1 0 0 1 1 0 1 0 1 1 0 0 1 0 1 0 0 0
negative ( 1+1/(2) +1/(16) +1/(256) +1/(512) +1/(1024) +1/(2048) +1/(8192) +1/(32768) +1/(65536) +1/(131072) +1/(4194304) +1/(8388608) )*2^1
positive ( 1+1/(2) +1/(4) +1/(16) +1/(32) +1/(64) +1/(512) +1/(1024) +1/(4096) +1/(16384) +1/(32768) +1/(262144) +1/(1048576) )*2^29
-- .../terra1/stub
@ bc
scale=15
( 1+1/(2) +1/(4) +1/(16) +1/(32) +1/(64) +1/(512) +1/(1024) +1/(4096) +1/(16384) +1/(32768) +1/(262144) +1/(1048576) )*2^29
999999999.999999446351872

就是这样。999999999的值实际上是

999999999.999999446351872

您也可以通过bc检查-3.14也受到干扰。不要忘记在bc中设置比例因子。

显示的金额是硬件内部的金额。通过计算它获得的值取决于设置的比例。我确实将比例因子设置为15。数学上，以无限的精度，它似乎是1000000000。

我可以补充一下吗；人们总是认为这是一个计算机问题，但如果你用手（以10为基数）计算，你就不能得到（1/3+1/3=2/3）=真，除非你有无穷大可以将0.333…加到0.333……就像（1/10+2/10）一样==基数2的3/10问题，您将其截断为0.333+0.333=0.666，并可能将其舍入为0.667，这在技术上也是不准确的。

用三进制数，三分之三不是问题——也许有人会问为什么你的十进制数学被打破了。。。

想象一下，以10为基数，例如8位数的精度工作。您检查是否

1/3 + 2 / 3 == 1

并了解到这返回错误。为什么？好吧，作为真实的数字

1/3=0.333….和2/3=0.666。。。。

在小数点后八位截断，我们得到

0.33333333 + 0.66666666 = 0.99999999

当然，这与1.00000000正好相差0.00000001。

具有固定位数的二进制数的情况完全类似。作为实数，我们有

1/10=0.0001100110011001100…（底座2）

and

1/5=0.00111001100110011001…（底座2）

如果我们把这些截成七位

0.0001100 + 0.0011001 = 0.0100101

而另一方面，

3/10=0.010011001100110011…（基数2）

被截断为七位的值为0.0100110，两者相差0.0000001。

确切的情况稍显微妙，因为这些数字通常以科学符号存储。因此，例如，我们可以将其存储为1.10011*2^-4，而不是将1/10存储为0.0001100，这取决于我们为指数和尾数分配了多少位。这会影响计算的精度位数。

结果是，由于这些舍入错误，您根本不想在浮点数上使用==。相反，您可以检查它们的差值的绝对值是否小于某个固定的小数字。

这里的大多数答案都用非常枯燥的技术术语来解决这个问题。我想用正常人能够理解的方式来解决这个问题。

想象一下，你正试图把披萨切成薄片。你有一个机器人披萨切割机，可以将披萨切成两半。它可以将整个披萨减半，也可以将现有的披萨减半，但无论如何，减半总是准确的。

那台披萨切割机动作非常精细，如果你从一整块披萨开始，然后将其减半，然后继续每次将最小的披萨片减半，你可以在披萨片太小甚至无法实现高精度功能之前，将其减半53次。此时，您不能再将非常薄的切片减半，但必须按原样包含或排除它。

现在，你如何将所有的切片以这样一种方式分割，使其达到披萨的十分之一（0.1）或五分之一（0.2）？真的想一想，试着解决它。如果你手边有一个神话般的精密披萨切割机，你甚至可以尝试使用真正的披萨

当然，大多数有经验的程序员都知道真正的答案，那就是，无论你切得多细，都无法用这些切片拼凑出十分之一或五分之一的披萨。你可以做一个非常好的近似值，如果你把0.1的近似值和0.2的近似值相加，你会得到非常好的0.3的近似值。

对于双精度数字（允许您将披萨减半53次的精度），小于或大于0.1的数字分别为0.09999999999999999167332731531132594682276248931884765625和0.1000000000000000055511151231257827021181583404541015625。后者比前者更接近0.1，因此，如果输入值为0.1，数字解析器将倾向于后者。

（这两个数字之间的区别是“最小切片”，我们必须决定是否包含，这会引入向上的偏差，或者排除，这会带来向下的偏差。最小切片的技术术语是ulp。）

在0.2的情况下，数字都是相同的，只是放大了2倍。同样，我们赞成略高于0.2的值。

注意，在这两种情况下，0.1和0.2的近似值都有轻微的向上偏差。如果我们加上足够多的这些偏差，它们会将数字推离我们想要的越来越远，事实上，在0.1+0.2的情况下，偏差足够高，从而导致的数字不再是最接近0.3的数字。

特别是，0.1+0.2实际上是0.1000000000000000055511151231257827021181583404541015625+0.0200000000000000011102230246251565404236316680908203125=0.30000000000000000444089209850062616169452667236328125，而最接近0.3的数字实际上是0.29999999999988897769753748434595763683319091796875。

另外，一些编程语言还提供了披萨切割机，可以将披萨切成十分之一。虽然这种披萨切刀并不常见，但如果你有机会切到一个，那么你应该在切到十分之一或五分之一的披萨片非常重要的时候使用它。

（最初发布在Quora上。）