Talk:Parsing/RPN to infix conversion: Difference between revisions

From Rosetta Code
Content added Content deleted
m (→‎Examples Incorrect: generated infix will still be wrong)
Line 10: Line 10:
: It's actually a matter of precedence rather than associativity. RPN per se doesn't need to worry about if an op is left or right associated, but for infix notation brackets are needed for ops at same precedence level. To wit: <code>1 2 3 + -</code> is <code>1 - (2 + 3)</code>, not the same as <code>1 - 2 + 3</code>. Generally the easiest way is wrap the expression with parens whenever you pop a binary op off the stack, which will be unsightly, but correct: <code>1 2 3 4 5 + + + +</code> becomes <code>(1 + (2 + (3 + (4 + 5))))</code> --[[User:Ledrug|Ledrug]] 05:49, 17 December 2011 (UTC)
: It's actually a matter of precedence rather than associativity. RPN per se doesn't need to worry about if an op is left or right associated, but for infix notation brackets are needed for ops at same precedence level. To wit: <code>1 2 3 + -</code> is <code>1 - (2 + 3)</code>, not the same as <code>1 - 2 + 3</code>. Generally the easiest way is wrap the expression with parens whenever you pop a binary op off the stack, which will be unsightly, but correct: <code>1 2 3 4 5 + + + +</code> becomes <code>(1 + (2 + (3 + (4 + 5))))</code> --[[User:Ledrug|Ledrug]] 05:49, 17 December 2011 (UTC)
:: Yes of course the RPN is correct. It's the generated infix that is wrong. As the examples I looked at don't even reference associativity when generating the infix nor do they generate parenthesis every time then they must be wrong. At least one of these parsing tasks wanted minimal parenthesis - it would have to be this one. The one example given just isn't a case where you'd notice. --[[User:Dgamey|Dgamey]] 14:58, 17 December 2011 (UTC)
:: Yes of course the RPN is correct. It's the generated infix that is wrong. As the examples I looked at don't even reference associativity when generating the infix nor do they generate parenthesis every time then they must be wrong. At least one of these parsing tasks wanted minimal parenthesis - it would have to be this one. The one example given just isn't a case where you'd notice. --[[User:Dgamey|Dgamey]] 14:58, 17 December 2011 (UTC)
::: Recommendation: Replace the example case with one that would exhibit the problem, or add a second example case which would exhibit the problem. Require that the RPN and infix forms expressions evaluate equally. --[[User:Short Circuit|Michael Mol]] 15:33, 17 December 2011 (UTC)

Revision as of 15:33, 17 December 2011

Other examples

The Ruby Quiz article mentions the following two additional examples:

    $ ruby postfix_to_infix.rb '56 34 213.7 + * 678 -'
    56 * (34 + 213.7) - 678
    $ ruby postfix_to_infix.rb '1 56 35 + 16 9 - / +'
    1 + (56 + 35) / (16 - 9)

--Paddy3118 20:19, 3 December 2011 (UTC)

Examples Incorrect

Several examples (i.e. Python, and TCL) don't deal with associativity correctly - the code doesn't even refer to the attribute - it's defined and not used. I'm not sure of the Ruby code. The following "1 2 + 3 4 + ^ 5 6 + ^" should produce "( ( 1 + 2 ) ^ ( 3 + 4 ) ) ^ ( 5 + 6 )". --Dgamey 04:03, 17 December 2011 (UTC)

It's actually a matter of precedence rather than associativity. RPN per se doesn't need to worry about if an op is left or right associated, but for infix notation brackets are needed for ops at same precedence level. To wit: 1 2 3 + - is 1 - (2 + 3), not the same as 1 - 2 + 3. Generally the easiest way is wrap the expression with parens whenever you pop a binary op off the stack, which will be unsightly, but correct: 1 2 3 4 5 + + + + becomes (1 + (2 + (3 + (4 + 5)))) --Ledrug 05:49, 17 December 2011 (UTC)
Yes of course the RPN is correct. It's the generated infix that is wrong. As the examples I looked at don't even reference associativity when generating the infix nor do they generate parenthesis every time then they must be wrong. At least one of these parsing tasks wanted minimal parenthesis - it would have to be this one. The one example given just isn't a case where you'd notice. --Dgamey 14:58, 17 December 2011 (UTC)
Recommendation: Replace the example case with one that would exhibit the problem, or add a second example case which would exhibit the problem. Require that the RPN and infix forms expressions evaluate equally. --Michael Mol 15:33, 17 December 2011 (UTC)