在java语言中使用==比较浮点数有什么问题？

Question

根据this java.sun page的说法，==是Java语言中浮点数的相等比较运算符。

但是，当我键入以下代码时：

if(sectionID == currentSectionID)

进入我的编辑器并运行静态分析，我得到："JAVA0078浮点值与==的比较“

使用==比较浮点值有什么问题？正确的做法是什么？

Answer 1

测试浮点数是否“相等”的正确方法是：

if(Math.abs(sectionID - currentSectionID) < epsilon)

其中epsilon是一个非常小的数字，如0.00000001，这取决于所需的精度。

Answer 2

浮点值可能会稍有偏差，因此它们可能不会报告为完全相等。例如，将一个浮点数设置为"6.1“，然后再次打印出来，您可能会得到类似于"6.099999904632568359375”的报告值。这是浮点数工作方式的基础；因此，您不希望使用相等来比较它们，而是在一个范围内进行比较，也就是说，如果浮点数与要比较的数字的差小于某个绝对值。

This上关于寄存器的文章很好地概述了为什么会出现这种情况；有用而有趣的阅读。

Answer 3

只是为了给出其他人所说的背后的原因。

浮点数的二进制表示有点烦人。

在二进制语言中，大多数程序员都知道1b=1d、10b=2d、100b=4d、1000b=8d

好吧，它也是以另一种方式工作的。

.1b=.5d，.01b=.25d，.001b=.125，...

问题是，没有确切的方法来表示大多数十进制数，如.1，.2，.3等。你所能做的就是用二进制近似。当打印数字时，系统会进行一些模糊取整，以便显示.1而不是.10000000000001或.999999999999 (它们可能与.1一样接近存储的表示形式)。

来自评论的编辑:这是一个问题的原因是我们的期望。我们完全期望在将2/3转换为十进制时，2/3会被篡改，无论是.7、.67还是.666667。但我们不会自动期望.1以与2/3相同的方式进行舍入--这正是正在发生的事情。

顺便说一句，如果你很好奇，它内部存储的数字是一个使用二进制“科学记数法”的纯二进制表示。因此，如果您告诉它存储十进制数10.75d，它将为10存储1010b，为小数存储.11b。所以它将存储.101011，然后在末尾保存一些比特，表示:将小数点向右移动四位。

(虽然从技术上讲，它不再是小数点，但现在它是一个二进制小数点，但是对于大多数人来说，这个术语不会让事情变得更容易理解，因为他们发现这个答案有任何用处。)