【讨论】为啥0.2+0.4 != 0.6(浮点数计算的精度问题)

网上有很多帖子讨论浮点数的精度问题，其中有如下命题：

1. 0.2+0.4= 0.600 000 000 000 000 1
2. 0.58*10=5.8，但0.58*100=57.999 999 999 999 99，0.58*1000=580

http://justjavac.iteye.com/blog/1864938， http://vb2005xu.iteye.com/blog/1863492等

都对此进行了解释。

 

首先，我们可以肯定的是：浮点数是不能完全表示实数集的（从信息论的角度很容易得出此结论），所以必然存在误差。

而对有误差的数据进行计算，会带来 累加误差。

 

这里讨论的都是二进制格式的浮点数表示，不包括十进制等其他进制的表示。

 

浮点数表示的误差

 

先简单介绍一下浮点数表示。大家不必自己计算，可以去 http://babbage.cs.qc.cuny.edu/IEEE-754/ 和 http://babbage.cs.qc.cuny.edu/IEEE-754.old/Decimal.html。后者可以看到实际的值。

justjavac对后者进行了汉化，地址是： http://justjavac.com/tools/ieee-754-floating-point-conversion-from-floating-point-to-hexadecimal.html

 

在IEEE标准中，浮点数用三元组 < 符号位s， 指数e， 有效数字t> 来表示 (-1) ^s×t×2 ^e。

 

整数的表示

 

对于十进制的整数，如果有效数字不太多，则是可以精确表示的。比如100 表示为(-1) ⁰× 1.1001×2 ⁶ 。

 

但是如果有效数字太多，则可能会出问题。比如对于12 345 678 901 234 567 000，即使使用了double（binary64）来表示，结果为1.010 101 101 010 100 101 010 011 000 110 011 101 011 000 111 110 000 1×2⁶³，但这个二进制表示其实代表的却是1.234 567 890 123 456 7e19。

 

小数0.6如何表示？

 

对于整数，二进制表示只会丢失有效数字，而不会有其他的编号。然而对于小数，则可能会很麻烦，因为小数的二进制表示可能是无限循环的。

 

比如，对于0.6,的binary64表示：

(0.6)₁₀ = (0.100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 100 1...)₂

            = (1.001 100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001...)₂×2^-1

 

于是，符号位s=0，指数e为-1，有效数字为1.001 100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001...

 

我们知道，binary64的有效数字最多有53位，也就是说

1.001 100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001... 的黄色部分需要被抛弃。

 

那么我们应该如何抛弃这部分数据呢？在IEEE中规定了若干舍入方法，一般来说，普遍使用的是roundTiesToEven方式来舍入。

 

roundTiesToEven方法：round到相邻的浮点数据上。如果两个浮点数据都一样近， 则round到最后一位是偶数的浮点数据上。

 

由此,0.6~=(-1)⁰×1.001 100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 1×2^-1。

 

再试试0.2和0.4

(0.2)₁₀ =(0.001 100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 1...)₂

            =(1.100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 1...)₂×2^-3 。

(0.4)₁₀ =(0.011 001 100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 0...)₂

            =( 1.100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 10...) ₂ ×2 ^-2 。

 

使用roundTiesToEven方式舍入黄色部分后，前面的部分加1。也即

 

0.2 =(1.100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 101 0)₂×2^-3

0.4 =(1.100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 101 0)₂×2^-2

 

其实，0.2和0.4的有效位数是一样的，只是指数不同。

 

到现在，我们可以发现。0.2和0.4都是向上取整的，也即浮点数表示的值比实际值是要大那么一丢丢的。

浮点数计算误差

浮点数在计算时也是有误差的。

比如对于0.2+0.4，0.2对应的指数是-3, 0.4对应的指数是-2。IEEE要求 结果应该优先使用-3作为指数（也即较小的指数值）。

当采用-3作为指数时，0.2和0.4需要表示成

 

0.2 =(  1.100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 101 0)₂×2^-3

0.4 =(11.001 100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 010   )₂×2^-3

 

可以看到，小数位后，0.4少了一位，我们需要用0补齐，然后计算加法。得到

 

0.2+0.4=(100.110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 100 111 0×2^-3)₂

 

规则化

 

0.2+0.4=(1.001 100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 001 110)₂×2^-1

 

我们又需要舍弃黄色部分了，在这里，由于它离两边是一样近的，于是我们round到最后一位是偶数的浮点数上，于是有

 

0.2+0.4=(1.001 100 110 011 001 100 110 011 001 100 110 011 001 100 110 011 010 0__)₂×2^-1

 

请注意：这里我们又往上取整了，也即此处的结果是比实际值要大那么一丢丢的。

 

而这个结果到底是多少呢？精确结果是0.600 000 000 000 000 088 817 841 970 012 523 233 890 533 447 265 625。

考虑到有效数字，小数点后只保留16位，所以需要舍弃黄色部分，其结果是0.600 000 000 000 000 1=0.600 000 000 000 000 0 + 1E-16。

 

0.2+0.4的最后那个1来自哪里？

1. 对0.2舍入时，我们偏大了一丢丢。>=1.5 × 2^-57
2. 对0.4舍入时，我们偏大了一丢丢。>=1.5 × 2^-56
3. 对0.2+0.4舍入时，我们偏大了一丢丢。= 1 × 2^-54
4. 在输出时，我们又偏大了一丢丢。

哈，我们连续三次偏大了一丢丢，也是偏大发了，就多出了哪个1来了。总共偏差>=(1.5 + 1.5 × 2 + 1 × 2×2×2) * 2 ^-57 = 1.5625 × 2 ^-54 >8.6e-17。考虑到在输出因为四舍五入，从而会多出最后的那个1。

 

最后的总结

1. 浮点数表示可能存在Round
2. 浮点数计算可能存在Round
3. 结果输出时可能存在Round

这些Round的累加可能会引起有效数字的最后一位偏大或偏小。

题外：对于0.2或0.4，如果采用其他的Round方法，则有可能0.2+0.4=0.6的。而具体采用何种Round，是由语言实现平台决定，或者程序指定的。