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

 
(7 intermediate revisions by 4 users not shown)
Line 15:
:::::: Thank you! --[[User:Dgamey|Dgamey]] 01:48, 18 December 2011 (UTC)
:: Huh, if you want minimum parentheses and follow the [[wp:Associativity|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. --[[User:Ledrug|Ledrug]] 17:50, 17 December 2011 (UTC)
::: I just realized that we are not using the same terminology at all. You've been talking about the '''associative property''' which is different from '''[[wp:Operator_associativity]]'''. This would tend to speak to slightly different backgrounds mathematics .vs. computer science (or at least parsing). The task description was originally correct from this perspective. But clearly not from the mathematical definition! The dangers of terminology overload. Ouch! --[[User:Dgamey|Dgamey]] 22:34, 19 December 2011 (UTC)
::: I didn't write it, I just noticed it was broken. Perhaps it should be knocked back to draft. --[[User:Dgamey|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. --[[User:Dgamey|Dgamey]] 18:19, 17 December 2011 (UTC)
Line 26 ⟶ 27:
:::::::: Yeah, ''that'' was a bug that needed an extra test case. :-) –[[User:Dkf|Donal Fellows]] 09:18, 19 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)
 
== On Minimal Parenthesis ==
After finding out the discussions on associativity (above) were working from different definitions, this discussion about parenthesis in the solution may make more sense than it did previously. The removal of the "minimal" from the requirement may have opened up the task to solutions having parenthesis everywhere. While this is certainly unambiguous, it is also just as certainly ugly. I'm not sure this meets the original authors intent and I wish they would chime in here one way or another. --[[User:Dgamey|Dgamey]] 22:48, 19 December 2011 (UTC)
 
== New Input examples ==
See 'Examples Incorrect' above. An example was added to show that associativity is correctly handled. --[[User:Dgamey|Dgamey]] 16:49, 17 December 2011 (UTC)
 
==Negation==
The table of operators needs to inculde an operator for negation. Should -4 8 ^ mean -(4 ^ 8) or (-4) ^ 8.
--[[User:Nigel Galloway|Nigel Galloway]] 12:52, 2 April 2012 (UTC)
 
:In RPN the negative number has no space between the minus sign and the first digit. Subtraction as an operator has spaces around the sign. --[[User:Paddy3118|Paddy3118]] 16:06, 7 May 2012 (UTC)
:I agree that that describes the prn side, but the problem is on the infix side. Infix notation assigns a higer priority to exponentiation than to unary negation. If I use the perl implementation:
<pre>
>rpn.pl
-4 2 ^
-4^2
</pre>
:Then I use the generated infix in perl:
<pre>
>perl
print -5 ** 2
^Z
-25
</pre>
:The correct infix is (-5)**2. The same is true for infix in Ruby and Python:
<pre>
irb(main):001:0> -4 ** 2
=> -16
Python 3.2.2 (default, Sep 4 2011, 09:51:08) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> -4 ** 2
-16
</pre>--[[User:Nigel Galloway|Nigel Galloway]] 14:19, 11 May 2012 (UTC)
 
== Extraneous Requirements ==
 
The requirement "Show how the major datastructure of your algorithm changes with each new token parsed" is entirely extraneous to the core task, and, I think, its inclusion goes against the principle mission of Rosetta code. For reasons outlined in [[Rosetta Code:Village Pump/Extraneous Printing Requirements in Tasks]], I think we should make this requirement optional. If no one objects after several days, I will make this minor change.