Just a heads up. The decimal button doesn't work if you max out the digits with a decimal place and then try to enter another number with a decimal place. My guess is the decimal variable doesn't get changed to false and therefore doesn't allow another decimal place. Should be a simple fix of setting decimal to false in the event of the digits maxing out.

It has been mentioned before (I believe in the gitter chat and maybe here somewhere) that this calculator is intended to only accept basic calculator operations for the challenge (one by one). I can understand where your thought might have came from if you look at the history list as a system accepting grouped inputs. I have had plans to update the calculator soon so it is a bit more clear to the student and to divert any potential confusion in the future. After seeing this, I will do an update in the next couple days!

5+1*10 should be 15 according to the operator precedence rules.

I noticed that this calculator just applies operations from left to right, it doesn't use the standard order of operations (PEMDAS).

It's pretty involved to implement order of operations. The most straightforward way IMO is to use reverse polish notation where you basically have a stack of tokens (numbers) and a stack of operators that you parse from the string and then recursively pop operators off the stack, apply the operation and push the result back onto the token stack. There's a good explanation on Wikipedia.

Someone should teach this calculator OOP

Just a heads up. The decimal button doesn't work if you max out the digits with a decimal place and then try to enter another number with a decimal place. My guess is the decimal variable doesn't get changed to false and therefore doesn't allow another decimal place. Should be a simple fix of setting decimal to false in the event of the digits maxing out.

Wow, great catch James @09jdphil ! You were the first to be able to find this well hidden, minor bug out of many developers who have reviewed it.

I looked into this and it will be an easy fix. I will correct it and have the code updated!

super handsome calc!

Order of operations is not correct!

Example: 5 + 1 * 10 gives 60

@MitkoM Thanks for looking for any faults!

It has been mentioned before (I believe in the gitter chat and maybe here somewhere) that this calculator is intended to only accept basic calculator operations for the challenge (one by one). I can understand where your thought might have came from if you look at the history list as a system accepting grouped inputs. I have had plans to update the calculator soon so it is a bit more clear to the student and to divert any potential confusion in the future. After seeing this, I will do an update in the next couple days!

Thanks for your feedback!

I think there is another bug:

3.3-3 = 0.29

also the rounding when dividing seems a bit inaccurate:

1/8 = 0.12

1/3 = 0.33

Interesting point about order of operation.

My Windows 10 built in calculator also gives 60 for 5+1*10. The calculator on my phone (stock android) gives 15 for the same sum.

5+1*10 should be 15 according to the operator precedence rules.

I noticed that this calculator just applies operations from left to right, it doesn't use the standard order of operations (PEMDAS).

It's pretty involved to implement order of operations. The most straightforward way IMO is to use reverse polish notation where you basically have a stack of tokens (numbers) and a stack of operators that you parse from the string and then recursively pop operators off the stack, apply the operation and push the result back onto the token stack. There's a good explanation on Wikipedia.

https://en.wikipedia.org/wiki/Reverse_Polish_notation