14. 浮点数算法：争议和限制

认识到这个幻觉的真相很重要：机器不能精确表达 1/10，你可以简单的截断 显示 真正的机器值。 这里还有另一个惊奇之处。例如，下面:

>>> 0.1 + 0.2
0.30000000000000004

需要注意的是这在二进制浮点数是非常自然的：它不是 Python 的 bug，也不是你的代码的 bug。你会看到只要你的硬件支持浮点数算法，所有的语言都会有这个现象（尽管有些语言可能默认或完全不 显示 这个差异）。

由于小数 2.675 是 2.67 和 2.68 的正中间，你可能期望的结果（二进制近似）2.68。这不是，因为当十进制字符串 “2.675” 转换为二进制浮点数，再换成一个二进制近似，其精确值:

2.67499999999999982236431605997495353221893310546875

这个问题在于存储 “0.1” 的浮点值已经达到 1/10 的最佳精度了，所以尝试截断它不能改善：它已经尽可能的好了。 另一个影响是因为　0.1 不能精确的表达 1/10，对10个 0.1 的值求和不能精确的得到 1.0，即:

>>> sum = 0.0
>>> for i in range(10):
...     sum += 0.1
...
>>> sum
0.9999999999999999

浮点数据算法产生了很多诸如此类的怪异现象。在“表现错误”一节中，这个 “0.1” 问题详细表达了精度问题。更完整的其它常见的怪异现象请参见 浮点数危害 。 最后我要说，“没有简单的答案”。还是不要过度的敌视浮点数！

Python 浮点数操作的错误来自于浮点数硬件，大多数机器上同类的问题每次计算误差不超过 2**53 分之一。对于大多数任务这已经足够让人满意了。但是你要在心中记住这不是十进制算法，每个浮点数计算可能会带来一个新的精度错误。

问题已经存在了，对于大多数偶发的浮点数错误，你应该比对最终显示结果是否符合你的期待。 str() 通常够用了，完全的控制参见字符串格式化中 str.format() 方法的格式化方式。