I’ve updated my Portfolio with a new project: an arithmetic Calculator.
What is the Calculator?
A GUI application that evaluates arithmetic expressions according to the rules of operator precedence.
Development
I started this project because I grew curious about how an algorithm that correctly evaluates an arithmetic expression might work.
As most of you probably know, you can’t simply go from left to right, performing each operation as you come across it, because multiplication/division take precedence over addition/subtraction. You also need to prioritize operations inside parentheses.
A bit of research led me to the shunting-yard algorithm, which can be used to convert expressions using infix notation (e.g., 1 + 2) into postfix notation (e.g., 1 2 +), which is easier for computers to evaluate.
I implemented a Java version of the algorithm as described here, then modified it as needed during the project’s development.
I used Swing to build the GUI. Rather than use a GUI builder, as I’ve done for a couple other personal projects, I chose to program the components myself.
In addition to the GUI buttons, the program accepts keyboard input.
Challenges
When implementing the shunting-yard algorithm, I initially had some trouble working out how to break an expression into tokens of varying lengths.
I found a solution by studying some example code, then doing something different that achieved the same result, thinking a different approach might make a good learning experience.
The proper handling of user input presented the greatest challenge during this project. Nothing prevents the user from entering an expression that makes my Evaluator class weep in utter despair.
Bad expressions usually throw an Exception with a “SYNTAX ERROR” message. But in some cases, the program will slightly modify the expression to reduce the number of these Exceptions.
During development, I also found that entering expressions of astonishing length stretched out the display area, along with a single column of buttons, in a way that looked unseemly. I addressed this by constraining the display area to a specific width.
When an expression reaches this width, the program temporarily disables all number and operator buttons, providing some visual feedback to users that their expression is quite long enough, thank you.
Mike Schulenberg 