The calculator seems to miss the point of recursive descent parsing. The parser should follow naturally from the grammar. As an example, here is a 52 line python calculator:
The idea isn't to 1-up the OP but rather to showcase the technique of recursive descent parsing. The wikipedia entry for recursive descent parsing also has a very nice example.
Clearly a bug. Thanks when I have more time I will fix it. I didn't give much thought to operator precedence, I assumed the user would specify it using parentheses.
The idea is what is important though. Recursive descent parsing uses the functions that correspond to types in the grammar to mutually call each other thus parsing the expression recursively in a descending fashion.
An analogous case is the programmer who relies on libraries and abstraction and "knows just enough to be dangerous." Statistics and optimization mathematics in particular are vulnerable to this. If you haven't read the proofs or you cannot prove it yourself, then you truly don't understand it. I'm not claiming this is you since your post doesn't imply that.
However as an example, if someone is solving linear or non-linear programs using <insert software or library here> but hasn't bothered to thoroughly study the mathematics underlying either and is just plugging in numbers from the constraint equations they came up with, then I would not want that person doing any sensitivity analysis. There would just be no way to be confident that they are interpreting the results correctly.
I've benefited from lots of theoretical classes, and you're absolutely right that you need to understand the theory of what you're doing. For example, I took a lovely class from Prof. John Hooker (at CMU) that derived Linear Programming duality as a natural consequence of Farkas' Lemma, rather than just mechanically grinding through LP tableau. I certainly followed the proofs discussed in many classes.
However, I can honestly say I got that understanding without doing hardly any proofs of my own. Graph theory was the only class where I "did proofs", and I didn't find it my favorite. (Later I did algorithmic graph theory and network flows - and that was fantastic, with no proofs.)
I guess my point is just that an engineer can understand and use a lot of pretty advanced math without spending much effort learning about proof techniques. That certainly wouldn't be how I'd spend my time. (Of course, if you enjoy doing that then knock yourself out.)
> Wikipedia is not designed to be a pedagogical repository; arguing that the mathematical language sucks because a terse summary in wikipedia is not enough to understand the material is missing the point.
Nicely worded. I think the real issue is that many people want mathematics to be easy to read and understand. Unfortunately, much of mathematics is not easy to read nor is it easy to understand regardless of how it is written. Mathematics, like many other things, often requires a lot of intellectual scaffolding to be built from the bottom up. There is no shortcut to the top.
