为什么改变求和顺序会返回不同的结果?
23.53 + 5.88 + 17.64 = 47.05
23.53 + 17.64 + 5.88 = 47.050000000000004
Java和JavaScript都返回相同的结果。
我知道,由于浮点数用二进制表示的方式,一些有理数(如1/3 - 0.333333…)不能精确地表示。
为什么仅仅改变元素的顺序就会影响结果?
为什么改变求和顺序会返回不同的结果?
23.53 + 5.88 + 17.64 = 47.05
23.53 + 17.64 + 5.88 = 47.050000000000004
Java和JavaScript都返回相同的结果。
我知道,由于浮点数用二进制表示的方式,一些有理数(如1/3 - 0.333333…)不能精确地表示。
为什么仅仅改变元素的顺序就会影响结果?
当前回答
浮点数使用IEEE 754格式表示,该格式为尾数(有效位)提供了特定的位大小。不幸的是,这给了你一个特定数量的“分数构建块”来玩,某些分数值不能精确地表示。
在您的情况下发生的情况是,在第二种情况下,由于计算加法的顺序,加法可能会遇到一些精度问题。我没有计算过具体的数值,可能是23.53 + 17.64不能精确表示,而23.53 + 5.88可以。
不幸的是,这是一个已知的问题,你必须处理。
其他回答
这是二进制的情况。正如我们所知,一些浮点值不能精确地用二进制表示,即使它们可以精确地用十进制表示。这三个数字只是事实的例子。
用这个程序,我输出了每个数字的十六进制表示形式和每次加法的结果。
public class Main{
public static void main(String args[]) {
double x = 23.53; // Inexact representation
double y = 5.88; // Inexact representation
double z = 17.64; // Inexact representation
double s = 47.05; // What math tells us the sum should be; still inexact
printValueAndInHex(x);
printValueAndInHex(y);
printValueAndInHex(z);
printValueAndInHex(s);
System.out.println("--------");
double t1 = x + y;
printValueAndInHex(t1);
t1 = t1 + z;
printValueAndInHex(t1);
System.out.println("--------");
double t2 = x + z;
printValueAndInHex(t2);
t2 = t2 + y;
printValueAndInHex(t2);
}
private static void printValueAndInHex(double d)
{
System.out.println(Long.toHexString(Double.doubleToLongBits(d)) + ": " + d);
}
}
printValueAndInHex方法只是一个十六进制打印机助手。
回显如下:
403787ae147ae148: 23.53
4017851eb851eb85: 5.88
4031a3d70a3d70a4: 17.64
4047866666666666: 47.05
--------
403d68f5c28f5c29: 29.41
4047866666666666: 47.05
--------
404495c28f5c28f6: 41.17
4047866666666667: 47.050000000000004
前4个数字是x、y、z和s的十六进制表示。在IEEE浮点表示法中,位2-12表示二进制指数,即数字的刻度。(第一个位是符号位,其余位是尾数位。)表示的指数实际上是二进制数减去1023。
提取前4个数字的指数:
sign|exponent
403 => 0|100 0000 0011| => 1027 - 1023 = 4
401 => 0|100 0000 0001| => 1025 - 1023 = 2
403 => 0|100 0000 0011| => 1027 - 1023 = 4
404 => 0|100 0000 0100| => 1028 - 1023 = 5
第一批新增功能
第二个数字(y)的大小较小。当这两个数字相加得到x + y时,第二个数字(01)的最后2位被移出范围,不计入计算。
第二次加法将x + y和z相加,并将两个相同比例的数相加。
第二组补充
这里,x + z先出现。它们具有相同的规模,但它们产生的数字在规模上更高:
404 => 0|100 0000 0100| => 1028 - 1023 = 5
第二次加法将x + z和y相加,现在从y中去掉3位来相加(101)。这里必须有一个向上的整数,因为结果是下一个向上的浮点数:对于第一组加法运算,4047866666666666 vs.对于第二组加法运算,4047866666666667。这个错误很大,足以显示在打印出来的总数中。
总之,在对IEEE数字执行数学运算时要小心。有些表示是不准确的,当尺度不同时,它们会变得更加不准确。如果可以,可以加减相似比例的数字。
乔恩的回答当然是正确的。在你的例子中,误差不会比你做任何简单浮点运算所积累的误差大。在这种情况下,一种情况下误差为零而另一种情况下误差很小;这其实不是一个有趣的场景。一个很好的问题是:是否存在这样的情况:改变计算的顺序会从一个微小的错误变成一个(相对)巨大的错误?答案无疑是肯定的。
举个例子:
x1 = (a - b) + (c - d) + (e - f) + (g - h);
vs
x2 = (a + c + e + g) - (b + d + f + h);
vs
x3 = a - b + c - d + e - f + g - h;
显然,在精确的算术中,它们是相同的。试图找出a, b, c, d, e, f, g, h的值,使得x1, x2和x3的值相差很大,这是很有趣的。看看你能不能做到!
为了给这里的其他答案添加一个不同的角度,这个SO答案表明,有一些方法可以进行浮点数学,其中所有求和顺序在位级上返回完全相同的值。
我认为这与评估的顺序有关。虽然和在数学世界中自然是一样的,但在二进制世界中,它不是a + B + C = D,而是
A + B = E
E + C = D(1)
这是第二步,浮点数可以脱离。
当你改变顺序时,
A + C = F
F + B = D(2)
浮点数使用IEEE 754格式表示,该格式为尾数(有效位)提供了特定的位大小。不幸的是,这给了你一个特定数量的“分数构建块”来玩,某些分数值不能精确地表示。
在您的情况下发生的情况是,在第二种情况下,由于计算加法的顺序,加法可能会遇到一些精度问题。我没有计算过具体的数值,可能是23.53 + 17.64不能精确表示,而23.53 + 5.88可以。
不幸的是,这是一个已知的问题,你必须处理。