user calculations

[JDShu]

So did you had a look at GNU Bison or something like that?

Yeah this seems good to know! At the moment its making my head explode and I've forgotten a lot of the stuff on grammar that I had to learn back in CS class haha.

[maraldi]

Try the open source parsers there are some really good, fast GPL ones.

[ve4cib]

Just to add some more grit to the mill, transforming in real time from "normal" to rpn is not quite trivial. take for example:

3 * (4 + 5)

which is 27

here's how to transform it to rpn (my thoughts are written in bash-style comments):

3 * (4 + 5)  # 3 is okay at the start, but then comes a star,
             # that's no good, let's move it to the right
3 ( * 4 + 5) # eek! not good, the * has to go to after the 
             # brackets. let's find the end of the balancing bracket
3 (4 + 5) *  # okay, that's better, but i haven't yet dealt with
             # the bracket. the 4 is okay, but the + isn't
3 (4 5 +) *  # perfect, well sort of.

the result should be:
3 4 5 + *

This method will fall apart if you put the operations in a different order though. For example:

3 + 4 * 5    # 3 is good, + isn't, so move it to the right
3 4 + * 5    # not enough arguments for a *, so move it to the right
3 4 + 5 *    # perfect, valid post-fix syntax
7 5 *        # evaluate 3 4 +
35           # evaluate 7 5 *

So the answer is 35. But wait a minute, 3 + 4 * 5 is 23! Darn that order of operations!

You can't just blindly move things to the right, compensating for parentheses. You would also need to check for the natural order of operations when building the tree, which adds to the complexity not insignificantly.

[JDShu]

Here's an example of a very simple C++ recursive decent parser that will do what you wanted.

It is an object oriented program but I'm sure you could modify it to work as a C program if you really have to.

You are the man (or woman)! I (messily) changed your code into something that works in C and its perfect! This is exactly what I wanted.

I'll definitely do more reading up on the theory and computer science-y stuff to get familiar, but this definitely solves my immediate problem. I'm embarrassed to admit that I don't understand it yet, but in the name of knowledge, I shall get to understand it better

[howlingmadhowie]

This method will fall apart if you put the operations in a different order though. For example:

3 + 4 * 5    # 3 is good, + isn't, so move it to the right
3 4 + * 5    # not enough arguments for a *, so move it to the right
3 4 + 5 *    # perfect, valid post-fix syntax
7 5 *        # evaluate 3 4 +
35           # evaluate 7 5 *

So the answer is 35. But wait a minute, 3 + 4 * 5 is 23! Darn that order of operations!

You can't just blindly move things to the right, compensating for parentheses. You would also need to check for the natural order of operations when building the tree, which adds to the complexity not insignificantly.

indeed, precedence is a terrible thing, which is why i much prefer languages like lisp, smalltalk and forth which have no concept of precedence (well, smalltalk does, but it's fairly simple)

oh, and btw, there are rules for evaluating precedence in rpn notation. these were pasted by tony earlier on and give the correct result if you start from the line containing "3 4 + 5 *".

[veko]

This is not really a solution for you, unless you implement the code into your program, but I've just got to mention this command line calculator utility:
http://www.sourcefiles.org/Productivity_Tools/Calculators/e-0.02718.tar.gz

I don't know who has written it, and I'm not really sure whether it's an example of good or bad coding habits, but in its simple austerity it's really ingenious piece of code.

That page has lots of other calculators with sources too. You might want to look at their code too to get some hints.