在下面的程序中,您可以看到,除0.5外,每个略小于0.5的值都四舍五入。
for (int i = 10; i >= 0; i--) {
long l = Double.doubleToLongBits(i + 0.5);
double x;
do {
x = Double.longBitsToDouble(l);
System.out.println(x + " rounded is " + Math.round(x));
l--;
} while (Math.round(x) > i);
}
打印
10.5 rounded is 11
10.499999999999998 rounded is 10
9.5 rounded is 10
9.499999999999998 rounded is 9
8.5 rounded is 9
8.499999999999998 rounded is 8
7.5 rounded is 8
7.499999999999999 rounded is 7
6.5 rounded is 7
6.499999999999999 rounded is 6
5.5 rounded is 6
5.499999999999999 rounded is 5
4.5 rounded is 5
4.499999999999999 rounded is 4
3.5 rounded is 4
3.4999999999999996 rounded is 3
2.5 rounded is 3
2.4999999999999996 rounded is 2
1.5 rounded is 2
1.4999999999999998 rounded is 1
0.5 rounded is 1
0.49999999999999994 rounded is 1
0.4999999999999999 rounded is 0
我使用Java 6更新31。
总结
在Java 6(可能更早)中,round(x)被实现为floor(x+0.5).1这是一个规范错误,恰恰针对这一病理情况Java 7不再强制执行这个破碎的实现
这个问题
0.5+ 0.4999999999999999994正好是1的双精度:
static void print(double d) {
System.out.printf("%016x\n", Double.doubleToLongBits(d));
}
public static void main(String args[]) {
double a = 0.5;
double b = 0.49999999999999994;
print(a); // 3fe0000000000000
print(b); // 3fdfffffffffffff
print(a+b); // 3ff0000000000000
print(1.0); // 3ff0000000000000
}
这是因为0.4999999999999999994的指数小于0.5,所以当它们相加时,它的尾数会移位,ULP会变大。
解决方案
从Java 7开始,OpenJDK(例如)是这样实现的
public static long round(double a) {
if (a != 0x1.fffffffffffffp-2) // greatest double value less than 0.5
return (long)floor(a + 0.5d);
else
return 0;
}
1. http://docs.oracle.com/javase/6/docs/api/java/lang/Math.html#round%28double%29
2. http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6430675(感谢@SimonNickerson找到这个)
3. http://docs.oracle.com/javase/7/docs/api/java/lang/Math.html#round%28double%29
4. http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7u40-b43/java/lang/Math.java#Math.round%28double% 29
我在JDK 1.6 32位上得到了相同的结果,但在Java 7 64位上,我为0.4999999999999999994得到了0,四舍五入为0,最后一行不打印。这似乎是一个虚拟机问题,但是,使用浮点,您应该期望在不同的环境(CPU, 32位或64位模式)上的结果有所不同。
而且,当使用整数或逆矩阵等时,这些位可以产生巨大的差异。
x64输出:
10.5 rounded is 11
10.499999999999998 rounded is 10
9.5 rounded is 10
9.499999999999998 rounded is 9
8.5 rounded is 9
8.499999999999998 rounded is 8
7.5 rounded is 8
7.499999999999999 rounded is 7
6.5 rounded is 7
6.499999999999999 rounded is 6
5.5 rounded is 6
5.499999999999999 rounded is 5
4.5 rounded is 5
4.499999999999999 rounded is 4
3.5 rounded is 4
3.4999999999999996 rounded is 3
2.5 rounded is 3
2.4999999999999996 rounded is 2
1.5 rounded is 2
1.4999999999999998 rounded is 1
0.5 rounded is 1
0.49999999999999994 rounded is 0
JDK 6中的源代码:
public static long round(double a) {
return (long)Math.floor(a + 0.5d);
}
JDK 7中的源代码:
public static long round(double a) {
if (a != 0x1.fffffffffffffp-2) {
// a is not the greatest double value less than 0.5
return (long)Math.floor(a + 0.5d);
} else {
return 0;
}
}
当值为0.4999999999999999994d时,在JDK 6中,它将调用floor,因此返回1,但在JDK 7中,if条件是检查该数字是否是小于0.5的最大双精度值。在本例中,该数字不是小于0.5的最大双精度值,因此else块返回0。
您可以尝试0.49999999999999999d,它将返回1,但不会返回0,因为这是小于0.5的最大双精度值。
下面的答案摘自Oracle bug报告6430675。请访问报告以获得完整的解释。
方法{Math, StrictMath。轮在操作上定义为
(long)Math.floor(a + 0.5d)
对于双重论证。虽然这个定义通常如预期的那样工作,但对于0x1,它给出了令人惊讶的结果1,而不是0。fffffffffffffp-2(0.49999999999999994)。
值0.4999999999999999994是小于0.5的最大浮点值。作为十六进制浮点字面值,它的值是0x1。fffffffffffp-2,等于(2 -2 ^52)* 2^ 2。==(0.5 - 2^54)。因此,和的准确值
(0.5 - 2^54) + 0.5
是1 - 2^54。这是两个相邻浮点数(1 - 2^53)和1之间的中间值。在Java使用的IEEE 754算术舍入到最接近偶数舍入模式中,当一个浮点结果不精确时,必须返回两个可表示的浮点值中包含精确结果的较近的一个;如果两个值相等接近,则返回最后一位为0的值。在这种情况下,add的正确返回值是1,而不是小于1的最大值。
虽然方法是按定义操作的,但这个输入的行为是非常令人惊讶的;规范可以修改为“四舍五入到最接近的长,四舍五入绑定”,这将允许更改此输入的行为。