【讨论】为啥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，是由语言实现平台决定，或者程序指定的。

评论

10 楼 thihy 2013-05-15  

jellyfish 写道

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


The error bound is Math.ulp(), assuming operations are +/-/*//. So we are safe most of the time.

However, when dealing with Math.exp(), we are in big trouble for large numbers.

哈，刚发现Math下面还有这个方法 ，3ks。

9 楼 thihy 2013-05-15  

justjavac 写道

chenjinbo1983 写道

用BigDecimal不就可以了

BigDecimal确实可以精确表示数，但是在计算数时，也无能为力。所以，还是有必要了解一下IEEE754，昨天把那个工具汉化了一下，http://justjavac.com/tools/ieee-754-floating-point-conversion-from-floating-point-to-hexadecimal.html

赞。但是原来的页面有一个不好的地方，“有效数字”的部分的Input有些短，总看不到后面的部分。要是能长一些就好了。

8 楼 justjavac 2013-05-15  

chenjinbo1983 写道

用BigDecimal不就可以了

BigDecimal确实可以精确表示数，但是在计算数时，也无能为力。所以，还是有必要了解一下IEEE754，昨天把那个工具汉化了一下，http://justjavac.com/tools/ieee-754-floating-point-conversion-from-floating-point-to-hexadecimal.html

7 楼 justjavac 2013-05-15  

thihy 写道

chenjinbo1983 写道

用BigDecimal不就可以了

实际使用时，如果对结果要求不是完整精确的，没有必要使用BigDecimal。而对于某些无理数，BigDecimal也无济于事。

这里主要是指明浮点数存在误差，所以在对浮点数进行操作时，要小心。不要潜意识地认为它是“精确的”。

对。BigDecimal不是终极解决办法，否则就没有必要使用浮点数了。BigDecimal是用定点数表示数字，所以，在范围是是有限的。

6 楼 jellyfish 2013-05-14  

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


The error bound is Math.ulp(), assuming operations are +/-/*//. So we are safe most of the time.

However, when dealing with Math.exp(), we are in big trouble for large numbers.

5 楼 thihy 2013-05-14  

chenjinbo1983 写道

用BigDecimal不就可以了

实际使用时，如果对结果要求不是完整精确的，没有必要使用BigDecimal。而对于某些无理数，BigDecimal也无济于事。

这里主要是指明浮点数存在误差，所以在对浮点数进行操作时，要小心。不要潜意识地认为它是“精确的”。

4 楼 chenjinbo1983 2013-05-14  

用BigDecimal不就可以了

3 楼 thihy 2013-05-13  

justjavac 写道

提点建议，<符号位s， 指数e， 有效数字t> 这行字加粗了。

我觉得，应该把文章中有用的，或者知识点加粗。那么长的010101串，最好按4位或者8位分隔开，这样容易看。

对于大串的0101，你在后面不一样的地方加黄色背景，很赞。希望其它的不利于阅读，不利于理解的格式也调整一下。让文章锦上添花。

这格式粘贴的。感觉HTML编辑器就是不如Word爽。有时间搞定一下。

2 楼 justjavac 2013-05-13  

提点建议，<符号位s， 指数e， 有效数字t> 这行字加粗了。

我觉得，应该把文章中有用的，或者知识点加粗。那么长的010101串，最好按4位或者8位分隔开，这样容易看。

对于大串的0101，你在后面不一样的地方加黄色背景，很赞。希望其它的不利于阅读，不利于理解的格式也调整一下。让文章锦上添花。

1 楼 justjavac 2013-05-13  

赞一个，比我写的详细。