My own infix to prefix approach. What do you think?

[HP67]

Ok, back to planet earth and the original topic.

(04-29-2014 12:47 AM)Matt Agajanian Wrote:  The way I see it is if I interpret each one or two number operation as func(arg1, arg2...) or func(arg), then, after writing this form of the expression out, I replace the parenthese and commas with spaces for readability and syntax, the end result is a prefix expression.

For example: (2+3)x(4+5) becomes x(+(2,3),+(4,5)).
Thus, replacing parentheses and commas with spaces gives x + 2 3 + 4 5 as the decomposed result.

Do you think my methodology is plausible and valid?

It's incomplete because it doesn't address areas not limited to operator and function call precendence and functions with variable numbers of arguments. In your example, all operators are binary. But that is only a subset of normal operators. For example what about -2 + 3? What about 5! + 4

How would you process unparenthesized expressions like

2 + 7 * 8

or

2 ^ 3 + 3

The IBM algorithm I mentioned earlier approaches this from a point of parenthesizing everything according to the rules of mathematics and then evaluating it after ambiguities have been removed. Dijkstra's method handles this by delaying the output of subexpressions while higher precedence operators are still on the stack.

What's neat about the Dijkstra algorithm is you can use it to generate numerous different kinds of outputs. You can create a postfix stream and since postfix doesn't have any order of operation ambiguity, you can actually evaluate the postfix stream as you're creating it and just output the result rather than the postfix.

Edit: That should have been "How would" not "Wow would". Edited, but too late since already quoted by Matt. Oops!