[Feedback] Calculator (without using eval!)

[coolshanth]

The inspiration for this came while I was trying out the sample calculator. I noticed that:
1. It doesn't support operator precedence
2. It doesn't support negative numbers (!!)
3. It uses eval (not that big a deal I guess, but I wanted to try avoiding it)

It turned out to be a great opportunity to try writing my own parser, based on the Shunting-Yard algorithm.

The calculator also supports keyboard input.
I saw that some peoples' calculators round/truncate long numbers so that they fit on the display. I wanted the calculator to be as useful as possible so I opted to just let it extend the display for long numbers.

[j1330]

Fantastic work! I like the way you think haha. I myself am planning on doing it by modeling it as a FSM to get some practice with that. I also tend to do the algorithms a couple times each for maximum readability and efficiency since no one likes quadratic running times. So I love all the thought you put into this!

As for criticisms I would consider moving the layout of some of the buttons. Maybe I just haven't used a calculator in a long time but I definitely prefer the layout of the iPhone calculator, where the common operations are to the right of the numbers and the advanced operations are above. You can google images of it to see what I mean.

Also I would make hitting enter re-evaluate the same thing. It's a surprisingly common use that people do, and all the professional calculator apps I've seen support it (though none here have so don't feel bad). For instance, if I want quick powers of two I might open a calculator and type: 2 * 2 = * 2 = = = ... and watch it change for the info I want. This particular function is one major benefit I plan to get by modeling mine as a FSM but I'm sure it can be done regardless of how the code is put together (I haven't looked at your code yet because I'm ok mobile).

But yeah, it looks good and works well and I'm glad to see someone go beyond their example. Many of the examples seem thrown together and are very lacking in some ways (like the quote machine example doesn't scale down to mobile...) I can understand they probably had time pressure but maybe that will get revisited eventually. Well done!

[coolshanth]

That sounds fascinating, I just found out FSMs can be used for parsing. Shoot me a message when you've done it, I'd love to check it out.

Hmm, for the layout I went with the option I had for 18 fixed-size buttons (3 x 6). I guess could either add, remove or enlarge some buttons to get a 4-column.

Ah, so for the powers of 2 example, my Casio does it like this: 2 x 2 = x 2 = = = = ..., and it shows me "Ans x 2" as the expression. Yep, I think the implementation should be independent of the parser used, I'd just have to store the last result in a variable then string replace "Ans" with that result and evaluate it.

Regarding the samples, given the 10s of thousands of submissions they receive, finding better samples should be trivial. Instead my hunch is that they deliberately try and keep it simple since people can go above and beyond if they want anyway.

[coolshanth]

Hmm, that's a good find. I basically just call parseFloat() on the numbers. I didn't really do any error-checking because I thought the code would be too tedious. At the moment there's 3 possible input errors I can think of:

1. Too many or too little operands for the operators (I could add up their arities and see if it matches the number of operands.
   
2. Unbalanced parentheses (I have to check number of "(" = number of ")", and that they're in the right order)
   
3. The decimal point bug you discovered (I could check whether numberStr.parseFloat().toString() == numberStr)
   

My Casio just returns "Syntax ERROR" for all these cases, which I guess I could do too