为什么更改总和顺序会返回不同的结果？
23.53 + 5.88 + 17.64 = 47.05
23.53 + 17.64 + 5.88 = 47.050000000000004
Java和JavaScript都返回相同的结果。
据我所知，由于浮点数用二进制表示的方式，一些有理数（如1/3 - 0.333333 ...... ）无法精确表示。
为什么简单地改变元素的顺序会影响结果？
答案 0 :(得分：275)
也许这个问题很愚蠢，但为什么简单地改变元素的顺序会影响结果呢？
它将根据其大小更改值舍入的点。作为我们所看到的事物的种的一个例子，让我们假设我们使用的是带有4位有效数字的十进制浮点类型而不是二进制浮点数，其中每次添加都是在“无限“精度，然后四舍五入到最接近的可表示数字。这是两个总和：
1/3 + 2/3 + 2/3 = (0.3333 + 0.6667) + 0.6667
= 1.000 + 0.6667 (no rounding needed!)
= 1.667 (where 1.6667 is rounded to 1.667)
2/3 + 2/3 + 1/3 = (0.6667 + 0.6667) + 0.3333
= 1.333 + 0.3333 (where 1.3334 is rounded to 1.333)
= 1.666 (where 1.6663 is rounded to 1.666)
我们甚至不需要非整数来解决这个问题：
10000 + 1 - 10000 = (10000 + 1) - 10000
= 10000 - 10000 (where 10001 is rounded to 10000)
= 0
10000 - 10000 + 1 = (10000 - 10000) + 1
= 0 + 1
= 1
这可能更清楚地表明，重要的部分是我们有有效数字的数量有限 - 而不是有限数量的小数位。如果我们总能保持相同的小数位数，那么至少加上和减法，我们就没事了（只要值没有溢出）。问题是当你得到更大的数字时，更小的信息会丢失 - 在这种情况下，10001被舍入到10000。 （这是Eric Lippert noted in his answer。）
的问题示例重要的是要注意右侧第一行的值在所有情况下都是相同的 - 所以尽管重要的是要理解你的十进制数（23.53,5.88,17.64）不会完全表示为double值，由于上面显示的问题，这只是一个问题。
答案 1 :(得分：52)
这是二进制文件中发生的事情。众所周知，某些浮点值无法用二进制精确表示，即使它们可以用十进制精确表示。这3个数字只是这个事实的例子。
使用这个程序，我输出每个数字的十六进制表示和每次加法的结果。
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与第二组加法的4047866666666667。该错误足以显示在总数的打印输出中。
总之，在对IEEE编号执行数学运算时要小心。一些表示是不精确的，当尺度不同时，它们变得更加不精确。如果可以的话，加上和减去相似比例的数字。
答案 2 :(得分：44)
Jon的回答当然是对的。在您的情况下，错误不会大于您在执行任何简单浮点操作时累积的错误。你有一个场景，在一种情况下，你得到零错误，在另一种情况下，你得到一个小错误;这实际上并不是一个有趣的场景。一个很好的问题是：是否存在更改计算顺序从微小错误变为（相对）巨大错误的情况？答案肯定是肯定的。
考虑例如：
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的值相差很大是很有趣的。看看你能否这样做！
答案 3 :(得分：10)
这实际上涵盖的不仅仅是Java和Javascript，并且可能会影响任何使用浮点数或双精度的编程语言。
在内存中，浮点使用IEEE 754的特殊格式（转换器提供了比我更好的解释）。
无论如何，这是浮动转换器。
http://www.h-schmidt.net/FloatConverter/
关于操作顺序的事情是操作的“细度”。
你的第一行从前两个值得到29.41，这给了我们2 ^ 4作为指数。
你的第二行产生41.17，它给出了2 ^ 5作为指数。
我们通过增加指数而失去一个重要的数字，这可能会改变结果。
尝试勾选最右边的最后一位开启和关闭41.17，您可以看到“无关紧要”的指数足以引起这个浮点差异。
编辑：对于那些记得重要数据的人来说，这属于那个类别。具有显着数字1的10 ^ 4 + 4999将是10 ^ 4。在这种情况下，有效数字要小得多，但我们可以看到附加了.00000000004的结果。
答案 4 :(得分：9)
浮点数使用IEEE 754格式表示，该格式为尾数（有效数字）提供特定的位大小。不幸的是，这会为您提供特定数量的“分数构建块”，并且某些小数值无法精确表示。
在您的情况下发生的情况是，在第二种情况下，由于评估添加的顺序，添加可能会遇到一些精确问题。我没有计算出这些值，但可能是23.53 + 17.64不能精确表示，而23.53 + 5.88可以。
不幸的是，这是一个已知的问题，你只需要处理。
答案 5 :(得分：6)
我认为这与评估的顺序有关。虽然总和在数学世界中自然是相同的，但在二进制世界中而不是A + B + C = D，它是
A + B = E
E + C = D(1)
因此浮点数可以下降的第二步。
当您更改订单时，
A + C = F
F + B = D(2)