以下哪个后缀表示法正确地表示中缀求和1+2+3+4？

Question

我正在测试一个中缀转后缀再转中缀的转换器，发现了一些不确定性。例如，一个简单的中缀求和

1 + 2 + 3 + 4

可以转换为后缀表达式

1 2 + 3 + 4 +

假设具有相等优先级的运算符没有被累积。如果它们被累积了，那么我就得到了：

1 2 3 4 + + +

另一方面，所有以下的后缀表达式都可以转换成初始和。

1 2 + 3 + 4 +
1 2 + 3 4 + +
1 2 3 4 + + +

这些后缀表达式都正确吗？

更新1

如果你要制作这样的转换器，你会选择哪种形式？我需要选择一种进行测试。

- Andrei

---

当然，使用前缀/后缀符号时，可能会出现n元运算而不是二元运算的问题，因此1234+可能是一个有效的表达式。 - jk.

Answer 1

您需要定义一个额外的约束条件。

在数学上，您的后缀表达式都是相同的。但是在计算机上，由于溢出，整数加法实际上并不是可交换的。

用a、b、c、d代替1、2、3、4，并考虑溢出的可能性。大多数编程语言定义必须从左到右评估a + b + c + d，以便a b + c + d +是唯一正确的翻译。

只有当您定义评估顺序为“未指定”时，所有后缀版本才是等效的。这是（旧版）C编译器的情况。

- H H

---

重要的是它们编译成与您所争论的相同的东西，而不是像其他人所争论的那样在数学上对于+运算符起作用。 - tster

大多数编程语言定义 a + b + c + d 必须从左到右进行评估。但是，大多数编程语言做什么与此有何关系呢？OP没有指定编程语言，对于抽象的中缀表达式，我不知道是否存在这样的从左到右的约定。尽管如此，我同意OP需要定义评估顺序。 - ShreevatsaR

@Shreev：主要的观点是+不是（真正的）可交换的。我认为你对其余部分读得太多了。 - H H

@Dolphin：是的，那又怎样？这是一个关于如何编程或编程的正确方式的编程问题。这与基于流行编程语言的人气比赛有什么关系呢？问题中没有提到特定的编程语言，根据你正在使用的编程语言，不同的结合顺序可能是正确的，从编程的角度来看。对你来说，这是否提到了足够多的“编程”？ :p - ShreevatsaR

@Shreev：考虑a+b+c，其中c为负数。(a+b)+c可能会溢出，而a+(b+c)则不会。 - H H

Answer 2

没错，它们对应以下中缀表达式：

((1 + 2) + 3) + 4
(1 + 2) + (3 + 4)
1 + (2 + (3 + 4))

- David

---

好的，没错。我的问题表述不够清楚 - 我想了解的是转换过程，而不是结果。 :) - Andrei

严谨地讲，唯一严格正确的顺序是第一个。其他方式是等效的，这是因为加法是可结合的。显然，它们都会给出相同的答案，但是 1441+++ 也会这样做。 - Joel

@Joel：为什么1+2+3+4的意思是((1+2)+3)+4而不是1+(2+(3+4))？有没有一些我没听说过的约定，中缀运算默认应该从左到右进行评估/左关联？（在许多编程语言中是这种情况，但这并不是普遍存在的。） - ShreevatsaR

事实上，在数学中，所有操作都是从左到右执行的，遵循运算顺序。对于加法来说无所谓，但对于其他运算可能会有影响。 - Joel

@ShreevatsaR：这对于向量叉积非常重要，因为它们既不是交换律也不是结合律。 - Joel

@Joel：我可以向您保证，在数学中，操作的左结合性远非普遍存在。以您提供的例子为例：对于向量叉积，a×b×c更可能表示向量三重积a×(b×c)，而不是(a×b)×c。函数组合f∘g∘h更可能表示f∘(g∘h)，而不是(f∘g)∘h。即使是矩阵乘法ABC也可能意味着(AB)C或A(BC)，这取决于约定。因此，至少这三个中的第一个和最后一个看起来同样有效，直到指定结合性（例如，通过引用现有编程语言的流行度）。 :P - ShreevatsaR

Answer 3

+很令人困惑 - 它是可交换的，因此实际上，每个结果都看起来是正确的。

考虑用其他运算符替换+：1 a 2 b 3 c 4。
对于左结合运算符，在这里的正确结果是

1 2 a 3 b 4 c

因此，在您的情况下，我预计会出现1 2 + 3 + 4 +。

- Kobi