为什么在 C# 中添加多个双精度数时顺序会影响舍入

Question

考虑以下 C# 代码：

double result1 = 1.0 + 1.1 + 1.2;
double result2 = 1.2 + 1.0 + 1.1;

if (result1 == result2)
{
    ...
}

result1 应该始终等于 result2，对吗？ 问题是，事实并非如此。 结果 1 为 3.3，结果 2 为 3.3000000000000003。 唯一的区别是常数的顺序。

我知道双打的实现方式可能会出现舍入问题。 我知道如果我需要绝对精度，我可以使用小数。 或者我可以在 if 语句中使用 Math.Round() 。 我只是一个想了解 C# 编译器在做什么的书呆子。 谁能告诉我吗？

编辑：

感谢迄今为止建议阅读浮点算术和/或谈论 CPU 处理双精度的固有不准确性的每个人。 但我觉得我的问题的主旨仍然没有得到解答。 这是我的错，因为措辞不正确。 让我这样说：

分解上面的代码，我希望发生以下操作：

double r1 = 1.1 + 1.2;
double r2 = 1.0 + r1
double r3 = 1.0 + 1.1
double r4 = 1.2 + r3

让我们假设上面的每个添加都有一个舍入错误（编号为 e1..e4）。 因此，r1 包含舍入误差 e1，r2 包含舍入误差 e1 + e2，r3 包含 e3，r4 包含 e3 + e4。

现在，我不知道舍入误差到底是如何发生的，但我预计 e1+e2 等于 e3+e4。 显然不是，但这对我来说似乎有些错误。 另一件事是，当我运行上面的代码时，我没有收到任何舍入错误。 这让我觉得是 C# 编译器而不是 CPU 在做一些奇怪的事情。

我知道我问了很多，也许任何人都能给出的最好答案就是去攻读 CPU 设计博士学位，但我只是想问一下。

编辑 2

查看我的原始代码示例中的 IL，很明显是编译器而不是 CPU 在执行此操作：

.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
    .maxstack 1
    .locals init (
        [0] float64 result1,
        [1] float64 result2)
    L_0000: nop 
    L_0001: ldc.r8 3.3
    L_000a: stloc.0 
    L_000b: ldc.r8 3.3000000000000003
    L_0014: stloc.1 
    L_0015: ret 
}

编译器正在为我添加数字！

Answer 1

我预计 e1+e2 等于 e3+e4。

并没有完全不同

 floor( 5/3 ) + floor( 2/3 + 1 )

这与期望相等

 floor( 5/3 + 2/3 ) + floor( 1 )

，只是在发言之前要乘以 2^53。

使用 12 位精度浮点并截断您的值：

1.0            =  1.00000000000
1.1            =  1.00011001100
1.2            =  1.00110011001

1.0 + 1.1      = 10.00011001100 // extended during sum
r1 = 1.0 + 1.1 = 10.0001100110  // truncated to 12 bit
r1  + 1.2      = 11.01001100101 // extended during sum
r2 = r1  + 1.2 = 11.0100110010  // truncated to 12 bit

1.1 + 1.2      = 10.01001100110 // extended during sum
r3 = 1.1 + 1.2 = 10.0100110011  // truncated to 12 bit
r3 + 1.0       = 11.01001100110 // extended during sum
r4 = r3  + 1.0 = 11.0100110011  // truncated to 12 bit

因此，更改运算/截断的顺序会导致错误发生变化，并且 r4 != r2。 如果在此系统中添加 1.1 和 1.2，则最后一位会进位，因此在截断时不会丢失。 如果将 1.0 添加到 1.1，则 1.1 的最后一位会丢失，因此结果不一样。

在一种排序中，舍入（通过截断）会删除尾随的 1。

在另一种排序中，舍入两次都会删除尾随 0。

一不等于零； 所以错误并不相同。

双精度数具有更多位的精度，并且 C# 可能使用舍入而不是截断，但希望这个简单的模型向您展示相同值的不同排序可能会发生不同的错误。

fp 和 maths 之间的区别在于 + 是“add then round”的简写，而不仅仅是加。

Answer 2

C# 编译器没有执行任何操作。 CPU是。

如果 CPU 寄存器中有 A，然后添加 B，则存储在该寄存器中的结果是 A+B，近似于所使用的浮点精度

如果然后添加 C，则误差会累加。 这个错误加法不是传递操作，因此是最终的区别。

Answer 3

请参阅经典论文（每个计算机科学家都应该了解浮点运算）< /a> 关于这个主题。 这种情况就是浮点运算中发生的事情。 计算机科学家才能告诉您 1/3+1/3+1/3 不等于 1...

Answer 4

浮点运算的顺序很重要。 不直接回答您的问题，但您应该始终小心比较浮点数。 通常包括容差：

double epsilon = 0.0000001;
if (abs(result1 - result2) <= epsilon)
{
    ...
}

这可能会令人感兴趣：每个计算机科学家应该做什么了解浮点运算

Answer 5

结果1应始终等于结果2
对吗？

错误。 在数学中确实如此，但在浮点算术中却不然。

您需要阅读一些数值分析入门。

Answer 6

为什么错误根据顺序不同可以用不同的示例来解释。

假设对于10以下的数字，它可以存储所有数字，因此它可以存储1、2、3等，直到10（包括10），但是在10之后，由于内部损耗，它只能存储每隔一个的数字精度，换句话说，它只能存储 10、12、14 等。

现在，通过该示例，您将了解为什么以下会产生不同的结果：

1 + 1 + 1 + 10 = 12 (or 14, depending on rounding)
10 + 1 + 1 + 1 = 10

浮点数的问题在于它们无法表示准确，并且错误并不总是以相同的方式发生，因此顺序很重要。

例如，3.00000000003 + 3.00000000003 最终可能是 6.00000000005（注意最后不是 6），但 3.00000000003 + 2.99999999997 最终可能是 6.00000000001，这样：

step 1: 3.00000000003 + 3.00000000003 = 6.00000000005
step 2: 6.00000000005 + 2.99999999997 = 9.00000000002

但是，改变顺序：

step 1: 3.00000000003 + 2.99999999997 = 6.00000000001
step 2: 6.00000000001 + 3.00000000003 = 9.00000000004

很重要。

当然，现在您可能很幸运，因为上面的示例相互平衡，第一个将向上摆动 .xxx1，另一个将向下摆动 .xxx1，从而为您提供两个 .xxx3，但不能保证。

Answer 7

实际上，您没有使用相同的值，因为中间结果不同：

double result1 = 2.1 + 1.2;
double result2 = 2.2 + 1.1;

因为双精度数不能准确地表示十进制值，所以您会得到不同的结果。