Anonymous user
Talk:Parsing/RPN to infix conversion: Difference between revisions
Talk:Parsing/RPN to infix conversion (view source)
Revision as of 02:42, 19 December 2011
, 12 years ago→Examples Incorrect: Must not mix things up
m (→Examples Incorrect: more on mimimal, etc) |
(→Examples Incorrect: Must not mix things up) |
||
Line 22:
::::: As I said, I didn't write the task. I just pointed out that it was broken. --[[User:Dgamey|Dgamey]] 01:48, 18 December 2011 (UTC)
::::: Hmmm, my definition of minimal in this case may not match the authors or yours but <code>1 2 3 + +</code> would be <code>1 + 2 + 3</code>. Which is both minimal (in my mind), and I think non-associative, which I would have thought arouse because <code>+</code> is commutative. Without belaboring the finer points I'd like to see it be both equivalent from infix and rpn and unambiguous. --[[User:Dgamey|Dgamey]] 01:48, 18 December 2011 (UTC)
:::::: Formally, <code>1+2+3</code> is the infix version of <code>1 2 + 3 +</code>, as addition is ''left''-associative in this exercise (the “normal” model for programming languages). Knowing that <code>1 2 3 + +</code> is also a way of writing that requires knowing that addition is ''fully'' associative, and I suspect that most people aren't going to model that. I know I don't intend to. (To confirm what I say, use the inverse of this task to parse the string; the type of structure it produces — or equivalently the RPN form it generates — is precisely determined by the defined associativity and precedence rules, with not mattering in this case.) I suppose we could implement all the code to allow your intuition to not be wrong, but then it wouldn't be a parsing/formatting task, but rather a general symbolic mathematics task. We ''must not'' conflate (A•B)•C with A•(B•C) when parsing! I believe that any task that generates A•B•C from both of those is necessarily wrong; after all, we've not described the differences between “+” and “-” to the computer, and the difference matters critically there. (What's more fun, with some type systems even “*” and “+” are not truly associative; [[C]] has such a type system, as do the plethora of languages derived from it, and it can be the source of many subtle bugs.) –[[User:Dkf|Donal Fellows]] 02:42, 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)
| |||