views:

129

answers:

3

I am testing an infix-to-postfix-to-infix converter and found some kind of uncertainty. For example, a simple infix sum

1 + 2 + 3 + 4

can be converted to postfix one

1 2 + 3 + 4 +

assuming that operators with equal precedence are not accumulated. If they are then I get

1 2 3 4 + + +

On the other hand, all the following postfix expressions can be converted to the initial sum

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

Are all these postfix expressions correct?

UPDATE1

If you would make such converter, to which form would you choose? I need to choose one for testing.

+5  A: 

Yep, all correct. They correspond to the following bracketed infix expressions:

((1 + 2) + 3) + 4
(1 + 2) + (3 + 4)
1 + (2 + (3 + 4))
David
OK, that's right. I wasn't clear in my question - I am curious about the conversion, not the result. :)
Andrey
To be pedantic, the only order that is strictly correct is the 1st. The others are equivalent, but only because addition is associative. Clearly, they all give the same answer, but then, so would 1441+++.
Joel
@Joel: Why does 1+2+3+4 mean ((1+2)+3)+4 and not, say, 1+(2+(3+4))? Is there some convention I've not heard of that infix operations are by default supposed to be evaluated left-to-right / be left-associative? (This happens to be the case in many programming languages, but it's not in any way universal.)
ShreevatsaR
It is, in fact, universal in mathematics for all operations to be performed left to right, subject to the order of operations. Again, for addition, it doesn't matter, but for other operations it might.
Joel
@ShreevatsaR: This is important for vector cross products, for instance, which are neither commutative, nor associative.
Joel
@Joel: I can assure you that in mathematics, it is far from universal to have operations left-associative. To take the example you gave: for vector cross products, a×b×c is more likely to mean the vector triple product a×(b×c) than to mean (a×b)×c. Function composition f∘g∘h is more likely to mean f∘(g∘h) than (f∘g)∘h. Even matrix multiplication ABC may mean either (AB)C or A(BC) depending on conventions. So at least the first and last of the three here seem equally valid, until associativity is specified (e.g. by appeal to popularity in existing programming languages. :P)
ShreevatsaR
+6  A: 

You need to define an extra constraint.

Mathematically, your postfix expressions are all the same. But on a computer integer addition is not really commutative because of overflow.

Replace 1 2 3 4 with a b c d and consider the possibility of overflow. Most programming languages define that a + b + c + d must be evaluated left-to-right so that a b + c + d + is the only correct translation.

Only when you define that the order of evaluation is 'unspecified' all the postfix versions are equivalent. That was the case for (older) C Compilers.

Henk Holterman
+1. The importance is that they compile to the same thing as you are arguing. Not that mathematically they work for the + operator as others are arguing.
tster
"Most programming languages define that a + b + c + d must be evaluated left-to-right" — Why is it relevant what most programming languages happen to do? The OP has not specified a programming language, and for infix expressions in the abstract, I don't know of any such left-to-right convention. I agree the OP needs to define the order of evaluation, though.
ShreevatsaR
@Shreev: The languages part is for illustrating the point that a def is required. And better re-read the evaluation rules of your fav. language. It matters.
Henk Holterman
@Henk: *Given* a programming language, it matters what *that* programming language does. Of course. I agree with you. But without being given any programming language (as here), I don't find it a good idea to make conclusions just based on what the majority of programming languages happen to do. :-)
ShreevatsaR
@Shreev: The main point was that `+` is not (really) commutative. I think you're reading too much in to the rest.
Henk Holterman
I agree with that completely. :-) Thanks,
ShreevatsaR
Dolphin
@Dolphin: Yes, so what? It's a programming question, about how to program it, or what the right thing to program is. What does this have to do with a popularity contest based on popular programming languages? There's no specific programming language mentioned in the question, and depending on what programming language you're writing, different orders of associativity can be correct, from the programming point of view. Does that mention "programming" enough times for you? :p
ShreevatsaR
@Henk: Returning to popular programming languages (though it wasn't mentioned in the question), I think integer addition is commutative in most languages I've encountered, even with overflow: whether it wraps around (mod 2^32) or saturates (gets set to max value), the results of a+b and b+a are the same. Do you know a case where they are not? Anyway, the issue here is not commutativity but associativity, and I agree that the order of operations can matter in cases where a, b, c, d are not just integers but expressions with side effects.
ShreevatsaR
@Shreev: consider a+b+c where c is negative. (a+b)+c might overflow where a+(b+c) might not.
Henk Holterman
+1  A: 

+ is confusing - it is commutative, so in fact, every result seems correct.

Consider replacing + with other operators: 1 a 2 b 3 c 4.
The correct result here, for left-associative operators, is

1 2 a 3 b 4 c

So, in your case, I'd expect 1 2 + 3 + 4 +

Kobi