又见浮点数精度问题

今天看到一篇文章：http://younglab.blog.51cto.com/416652/241886，大概是说在使用Javascript进行下面的浮点数计算时出现了问题：

obj.style.opacity = (parseInt(obj.style.opacity *100) + 1)/100;

obj.style.opacity是一个浮点数，范围从0~1，初始值为0。这句代码每隔一小段时间执行一次，从而让目标由透明慢慢变为不透明（淡入效果）。

问题是，起初obj.style.opacity还能够按照预期的每次以0.01逐步增加，但增加到0.29时就一直保持不变了。

作者只是记录了这个问题，没有写出为什么。读完这篇博客后我的第一感觉是：

这又是一个由于浮点数精度所引发的问题。

下面让我们来写一个小程序重现一下这个问题：

double opacity = 0;
for (int i = 0; i < 100; i++) {
opacity = ((int) (opacity * 100 + 1)) / 100.0;

System.out.println("opacity=" + opacity);
}

程序是用Java写的，共执行100次循环，采用了与那篇文章中相同的计算方法。正常情况下opacity会由0逐步增大到1。

程序输出如下：



可以发现，当opacity达到0.29后便不再增加了。由于Java和JS使用的是相同的浮点数格式，所以采用Java和JS结果都是相同的。

这里有一个细节需要注意：在这段程序中，除数必须写成100.0。这是由于在Java中有整数除法和浮点数除法两种不同的运算，如果写成100，那么被除数和除数将都是整数，Java就会按照整数除法来计算，就会导致每次计算的结果都是0（因为每次计算的结果都小于1，因此取整后就变为了0）。JS里没有这个问题，因为JS没有整数除法，所有除法都会当成浮点数除法来对待。

深入分析

现在我把上面那个程序做一点修改：

double opacity = 0;
for (int i = 0; i < 100; i++) {
opacity = ((int) (opacity * 100 + 1)) / 100.0;

System.out.println("opacity=" + new BigDecimal(opacity));
System.out.println("opacity*100=" + new BigDecimal(opacity * 100));
System.out.println("----------------------------");
}

因为Java在将浮点数转换为字符串时会做一些处理，让结果看起来更“美观”一些，但这样会让我们无法看清楚程序运行的真实情况。

在这个程序中我借助BigDecimal来显示浮点数在内存中的真正的样子。BigDecimal有一个以double数字为参数的构造方法，该方法会完整拷贝此double参数在内存中的位模式，它的toString( )方法也会严格按照实际的值进行转换，而不会为了“美观”而做任何处理。因此我们可以利用这种方法来看清一个double的“真面目”。

程序输出如下：



可以发现，当opacity的值为0.29时，实际上在内存中的准确值是0.2899999……，所以乘以100变成28.99999……，这比29要稍微小那么一点点。但就是少了这一点点，当强制转换为整数后的结果却是28而不是期望的29。而这正是导致这个问题的原因所在。

从这个程序的运行结果中我们还可以观察到以下几个现象：

1. 每个中间结果例如0.01、0.02……等等，都无法用double类型精确表示

2. 即使本身无法精确表示，但在0.28之前，opacity*100的结果却都是精确的

3. 在无法精确表示的数中，有些比真实值略大，而有些却比真实值略小。如果是前者，当截断小数位转成整型时得到的结果是“正确”的；但如果是后者则会得到错误的结果。例如0.28*100转成整型为28，而0.29*100转成整型不是29而是28。

如何改正

经过前面的分析，现在我们已经弄明白了问题产生的原因，那么该如何修正它呢？

之前的代码之所以无法正确运行，其根本原因在于一个double类型的数字强制转换为整型时会发生截断，这会导致小数部分全部丢失，然而计算的中间结果中有一些要比期望的整数值略小，截断小数位以后得到的是比期望值小1的值。

因此我们可以从以下两个方面着手修正此问题：一是从代码中去除强制转换操作；或者，保证截断之前的中间结果一定是比期望值略大的。

方法1. 去除强制转换

程序的目的是让opacity的值每次增加0.01，那么就只需要每次加上0.01就好了，完全不需要绕圈子。如下：

double opacity = 0;
while (opacity < 1) {
opacity += 0.01;
System.out.println("opacity=" + opacity);
}

这个程序简单、直接，而且没有任何问题。我个人推荐这个方法。该程序输出如下：

方法2. 保证截断之前的中间结果略大于期望值

既然原程序的问题发生在截断时，那么只要保证截断发生之前，中间结果的值略大于期望值，就能保证程序的正确性。例如如果要让截断后的结果为29，只要保证截断前的值在[29, 30)这个范围内即可。

如何做到这一点呢？

由于我们可以肯定在这个问题中，opacity*100的结果是非常接近我们所期望的整数的，只是由于double类型的精度限制而比期望的整数略大或略小而已，其误差一定非常非常小。

所以我们可以修改这句代码：

opacity = ((int) (opacity * 100 + 1)) / 100.0;

不是给opacity * 100加上1，而是加一个更大一些的数，例如1.5，变为：

opacity = ((int) (opacity * 100 + 1.5)) / 100.0;

如果我们期望的值是29，那么修改后的中间结果一定是在29.5附近，这样就能保证截断后的值一定是29了。程序如下：

double opacity = 0;
for (int i = 0; i < 100; i++) {
opacity = ((int) (opacity * 100 + 1.5)) / 100.0;

System.out.println("opacity=" + opacity);
}

输出为：



可以看到结果是正确的。

总结

只要稍有经验的程序员都知道浮点数不能直接进行相等比较，但是像这篇文章中所碰到的问题可能并不那么常见，因此有时不容易意识到发生了问题。

每个程序员都应该知道计算机中是采用近似值来保存浮点数的，当进行浮点数相关的计算时，需要时刻提防由于精度问题所导致的误差，并注意避免那些会影响到结果正确性的误差（所谓正确性，就是误差超出了所允许的最大范围）。

源码下载：https://github.com/terry83299387/MyTest/tree/master/FloatTest

附：

下面这个网页列举了历史上的一些由于计算问题引起的软件灾难，其中一例是1996年欧洲航天局的Ariane 5火箭发射失败事件，该火箭发射后仅40秒即发生爆炸，导致发射基地的2名法国士兵死亡，并导致历时近10年、耗资达70亿美元的航天计划严重受挫。事后调查报告显示问题的原因出在火箭的惯性参考系的软件系统中，其中有一个地方是将水平方位的64位浮点数转换为一个16位的整数，当浮点数的值超过32767时，转换就会失败（即转换的结果是错误的），从而导致了悲剧的发生。

http://ta.twi.tudelft.nl/users/vuik/wi211/disasters.html