为什么有些数字以浮点数存储时会失去精度？
例如，十进制数 9.2 可以完全表示为两个十进制整数的比率（92/10），这两个整数都可以用二进制表示并且能够完全表示（0b1011100/0b1010）。然而，将相同的比率存储为浮点数时，它永远不会完全等于 9.2：
32-bit "single precision" float: 9.19999980926513671875
64-bit "double precision" float: 9.199999999999999289457264239899814128875732421875
一个看似简单的数字怎么可能“太大”以至于在64位内存中无法表示呢？
在大多数编程语言中，浮点数的表示方式与科学计数法非常相似：它包含一个指数和一个尾数（也称为有效数字）。一个非常简单的数，比如9.2，实际上可以表示为以下分数：
5179139571476070 * 2 -49
其中指数为-49，尾数为5179139571476070。无法用这种方式表示某些十进制数的原因是指数和尾数都必须为整数。换句话说，所有浮点数都必须是一个整数乘以2的整数次幂。
9.2可能只是92/10，但如果将n限制为整数值，10就不能表示为2n。
首先，有几个函数可以“查看”组成32位和64位float的组件。如果您只关心输出结果，请忽略这些（示例使用Python）：
def float_to_bin_parts(number, bits=64):
if bits == 32: # single precision
int_pack = 'I'
float_pack = 'f'
exponent_bits = 8
mantissa_bits = 23
exponent_bias = 127
elif bits == 64: # double precision. all python floats are this
int_pack = 'Q'
float_pack = 'd'
exponent_bits = 11
mantissa_bits = 52
exponent_bias = 1023
else:
raise ValueError, 'bits argument must be 32 or 64'
bin_iter = iter(bin(struct.unpack(int_pack, struct.pack(float_pack, number))[0])[2:].rjust(bits, '0'))
return [''.join(islice(bin_iter, x)) for x in (1, exponent_bits, mantissa_bits)]
那个函数背后有很多复杂性，解释起来会很离题，但如果你感兴趣的话，对我们来说重要的资源是struct模块。
Python的float是64位双精度数字。在其他语言中，如C、C++、Java和C#，双精度有一个单独的类型double，通常实现为64位。
当我们使用示例9.2调用该函数时，我们得到以下结果：
>>> float_to_bin_parts(9.2)
['0', '10000000010', '0010011001100110011001100110011001100110011001100110']
你会看到我将返回值分成了三个组成部分。这些组成部分包括：
符号以单个位存储在第一个组成部分中。很容易解释：0表示浮点数是正数；1表示浮点数是负数。因为9.2是正数，所以我们的符号值是0。
0b10000000010。换算成十进制，表示的值是1026。这个组件的一个特殊之处是，你必须减去一个等于2(位数) - 1 - 1的数字才能得到真正的指数；在我们的例子中，意味着要减去0b1111111111（十进制数1023），得到真正的指数0b00000000011（十进制数3）。
尾数将是6.0221413。请记住，科学计数法中的尾数始终以一个非零数字开头。对于二进制来说也是如此，只不过二进制只有两个数字：0和1。因此，二进制尾数总是以1开头！当存储浮点数时，二进制尾数前面的1被省略以节省空间；我们必须将其放回到第三个元素的开头，以获得真正的尾数。6.0221413x1023
这不仅仅是简单的加法，因为我们第三个组件中存储的位实际上代表了尾数的小数部分，在小数点的右侧。1.0010011001100110011001100110011001100110011001100110
在十进制表示法中，这相当于将675539944105574除以4503599627370496得到0.1499999999999999。（这是一个比率的例子，在十进制中可以准确表示，但在二进制中只能近似表示；有关更多详细信息，请参见：675539944105574 / 4503599627370496。）0.0010011001100110011001100110011001100110011001100110
将这三部分放在一起，我们得到以下二进制数：
1.0010011001100110011001100110011001100110011001100110 x 1011
然后我们可以将其从二进制转换为十进制：
1.1499999999999999 x 23（不精确！）
通过乘法运算，我们可以得到最终表示我们开始时的数字（9.2），该数字被存储为浮点值。
9.1999999999999993
9.1999999999999993
>>> float_to_bin_parts(9.5)
['0', '10000000010', '0011000000000000000000000000000000000000000000000000']
9.5
这不是一个完整的答案（mhlester已经涵盖了很多我不会重复的好内容），但我想强调数的表示在很大程度上取决于你所使用的进制。
在基数为10的情况下，我们通常将其写成以下形式：
当我们看到这些表示时，我们倾向于将每个表示与分数2/3相关联，即使只有第一个表示在数学上等于该分数。第二个和第三个表示或近似值的误差约为0.001，这实际上比9.2和9.1999999999999993之间的误差还要糟糕得多。事实上，第二个表示甚至没有正确地舍入！尽管如此，对于0.666作为数字2/3的近似值，我们并没有问题，因此我们在大多数程序中对9.2的近似值也不应该有问题。（是的，在某些程序中这很重要。）
所以在这里进制非常关键。如果我们试图在基数为3的情况下表示2/3，则
(2/3)10 = 0.23
换句话说，通过转换进制，我们可以得到相同数的精确有限表示！结论是，尽管你可以将任何数字转换为任何进制，所有有理数在某些基数下具有精确的有限表示，但在其他基数下则不然。
为了更好地说明这一点，让我们来看看1/2。这个完全简单的数字可能会让你惊讶，即使这个数字在10进制和2进制中都有精确表示，但在3进制中需要一个重复的表示。
(1/2)10 = 0.510 = 0.12 = 0.1111...3
为什么浮点数不准确？
因为它们通常是用二进制近似表示无法有限表示的有理数（数字重复），并且一般来说，它们是近似表示实数（可能是无理数），在任何进制下都不能用有限位数表示。
N或其倍数的分数。 - Nicu Stiurca虽然其他答案都不错，但还有一点遗漏：
无法精确表示无理数（例如π、sqrt(2)、log(3)等）！
这也是它们被称为无理数的原因。世界上无论存储比特数量多少，都无法精确表示它们。只有符号算术才能保持它们的精度。
尽管如果你的数学需求仅限于有理数，那么精度问题就可以得到解决。你需要存储一对（可能非常大的）整数a和b来表示由分数a/b表示的数字。所有的算术运算都必须基于分数，就像在高中数学中一样（例如，a/b * c/d = ac/bd）。
但当涉及到pi、sqrt、log、sin等时，你仍然会遇到同样的麻烦。
简而言之
对于硬件加速算术，只能表示有限数量的有理数。每个不能表示的数字都将被近似。某些数字（即无理数）无论使用何种系统，都永远无法表示。