I think that SirCmpwn is avoiding a large memory footprint by avoiding the use of trees (which unfortunately causes a tradeoff to large CPU usage to parse a particular expression, which is fine as far as design decisions go, in my opinion).

I can see both sides. The only reason why I use trees is because the algorithms can be generic and small in code size (and because GlassOS gives programs loads of memory). For this parser, I can see it running faster than mine when working with larger expressions and it will be easier to parse output from a calculation (with mine giving the answer as either a tree or a string). Also, functions would be better to parse than with a tree.

I'm sure that the more interesting part will come when these systems can compete with other calculators in functionality (come on, these are calculators)

</rant from school whilst bored>

SirC, any progress with this expression parser? I am curious as to how you handle certain types of functions such as sqrt and powers... Would you leave these as exact answers or as approx? (2*sqrt(2) instead of getting a decimal answer)