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

From Rosetta Code
Content added Content deleted
(→‎Examples Incorrect: Leave commutativity out of this!)
Line 16: Line 16:
:::: By adding the extra example in a table other examples could be added easily. Although for output, perhaps suppressing the detail for all but one case would be appropriate. --[[User:Dgamey|Dgamey]] 18:19, 17 December 2011 (UTC)
:::: By adding the extra example in a table other examples could be added easily. Although for output, perhaps suppressing the detail for all but one case would be appropriate. --[[User:Dgamey|Dgamey]] 18:19, 17 December 2011 (UTC)
::: Sorry I thought what you were talking about is if an operator is commutative? --[[User:Dgamey|Dgamey]] 18:19, 17 December 2011 (UTC)
::: Sorry I thought what you were talking about is if an operator is commutative? --[[User:Dgamey|Dgamey]] 18:19, 17 December 2011 (UTC)
:::: The RPN code shouldn't try to use commutativity, as that causes problems in situations where there are side-effects. (OK, not in ''this'' example, but in general.) While a few languages allow optimizers to use it (notably [[C]] and [[C++]]), most don't because it causes much confusion; overall, language designers have found it better to be more predictable than that (where side-effects are present at all, of course). –[[User:Dkf|Donal Fellows]] 18:59, 17 December 2011 (UTC)
: Tcl version is now fixed (it would have helped if the original example had been sensitive to such things, but there you go). –[[User:Dkf|Donal Fellows]] 18:59, 17 December 2011 (UTC)


== New Input examples ==
== New Input examples ==

Revision as of 18:59, 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)
I added an extra example, now sadly all the tasks are wrong (although I think a couple already address this). The task already requires the RPN and infix to be the same. One thing, I can't find the template that says (globally) the task changed. So I'll have to mark them all incorrect if I can't find one. --Dgamey 16:49, 17 December 2011 (UTC)
Huh, if you want minimum parentheses and follow the actual definition of associativity, the task itself is incorrect: - and / are non-associative. The term "left-associative" is often loosely used when parsing infix notations, to determine the order of ops in absence of parens, but to do the reverse and requiring minimum number of parens, this kind of definition of associativity is not enough, and you need to know the exact behaviour of the operators (a + b + c requires none, but a - b - c may need one pair, even though both + and - are both loosely "left associative"). The task needs some more work, or there may be other holes after people try to fix the solutions. --Ledrug 17:50, 17 December 2011 (UTC)
I didn't write it, I just noticed it was broken. Perhaps it should be knocked back to draft. --Dgamey 18:20, 17 December 2011 (UTC)
By adding the extra example in a table other examples could be added easily. Although for output, perhaps suppressing the detail for all but one case would be appropriate. --Dgamey 18:19, 17 December 2011 (UTC)
Sorry I thought what you were talking about is if an operator is commutative? --Dgamey 18:19, 17 December 2011 (UTC)
The RPN code shouldn't try to use commutativity, as that causes problems in situations where there are side-effects. (OK, not in this example, but in general.) While a few languages allow optimizers to use it (notably C and C++), most don't because it causes much confusion; overall, language designers have found it better to be more predictable than that (where side-effects are present at all, of course). –Donal Fellows 18:59, 17 December 2011 (UTC)
Tcl version is now fixed (it would have helped if the original example had been sensitive to such things, but there you go). –Donal Fellows 18:59, 17 December 2011 (UTC)

New Input examples

See 'Examples Incorrect' above. An example was added to show that associativity is correctly handled. --Dgamey 16:49, 17 December 2011 (UTC)