Improve clarity of math expressions in history for Standard Calculator

[g-plane]

Describe the bug
Operators precedence in standard mode seems wrong, but works correctly in scientific mode.

Steps To Reproduce

1. Use standard mode.
2. Type: 75×0.3+60×0.7 (which equals to 75*0.3 + 60*0.7)
3. Press Enter
4. Now you will get the wrong result.
5. Switch to scientific mode.
6. Type the same expression above and submit it.
7. Now you can get the correct result.

Expected behavior
75*0.3 + 60*0.7 should be 64.5. However, the calculator will show the wrong result in standard mode.

Screenshots
Standard mode:

Scientific mode:

Device and Application Information (please complete the following information):

• OS Build: Windows 10 1803 build 17134.590
• Architecture: x64
• Application Version: 10.1811.3241.0

Possible solution (additional)
According to the disscusion of this issue, the calculation is expected. The bug is of the "History Panel". Some folks advised to add parens for expressions to be not confusing.

[yatli]

@g-plane standard mode calculates immediately before the next operator is armed, just like a "dumb tabletop calculator".

I do agree the expression in the calc history is confusing.

[g-plane]

just like a "dumb tabletop calculator"

Is this an expected behavior?

[yatli]

just like a "dumb tabletop calculator"

Is this an expected behavior?

not on the relevant team but I believe so. :)

The history page could use the following improvement:

- do not wait until a "=" to send the entry to the history
- instead, react on each key stroke (or button push)
- so the history view becomes a vertical list of key-in logs. this will cancel the confusion about operator precedence.
- one can select a range of key-ins in the history view to recall the list of actions into the calculator.

[MovGP0]

I agree that this is the wrong behaviour, but I also guess that this is intentionally for folks who are used to those 'financial' (aka. cheap crap) calculators.

[lxsmnsyc]

I think this was an intentional behavior, similar behavior to that of a cheap calculator.

[grochocki]

Thanks for the report! I really appreciate your thoroughness when filing this bug.

Is this an expected behavior?

Yes, this is by design. Standard Calculator mode works in immediate-execution mode, just as a simple pocket calculator would. It ignores order of operations entirely. The solution today would be to use Scientific Calculator, though we have discussed this on the team in the past and agree we can do better at making this distinction clearer.

@yatli I think you are onto something with your suggested improvement to address the confusion with this.

I am going to close this bug as by design for now, but we welcome suggestions on how to improve this experience. Take a look at the pitch tempalte in our New Feature Process to get started.

[KashifFaraz]

I agree that this is the wrong behaviour, but I also guess that this is intentionally for folks who are used to those 'financial' (aka. cheap crap) calculators.

This also gives a wrong result on Windows 7 Calculator in Standard Mode.

[Fabian42]

@grochocki There was already a suggestion made by @yatli and I agree with it. Should there be a new "issue" about it or should this one be edited?

[ssylvan]

If your app ever prints "5+5*5=50", then that is a bug. The app is giving incorrect results. At the very least you need to print that out with parenthesis so that what you're saying is correct. Closing this as by design is ridiculous. You may have intended for it to behave this way, but that doesn't make it okay.

The fix is simple (or I should say, it should be simple - I must confess I find this code base hopelessly hard to navigate/understand and couldn't figure out how to make this simple change in a reasonable period of time).

Just like the physical calculator whose behavior you're trying to emulate: simply insert an implicit "Enter" key after each binary operator. That way after each operator, the result is evaluated and put in the "ans" slot, so that it can be used for the next operation. This makes it explicit that each binary operator is "eagerly" evaluated (rather than the current behavior, where you make it appear as if you're building up the whole expression, and then just going off and evaluating it incorrectly.. but also not giving any indication that this is what you did).

You can simulate this manually in the calculator and it works fine. For example, the 5+5*5 example would be 5+5 enter *5 enter and would look like this:

Crystal clear what's going on, works just like old physical calculators (and prints results similarly to them), and no more "5+5*5=50" incorrect output.

EDIT: I see that this is exactly what @yatli suggested.

[g-plane]

As @ssylvan mentioned, I hope this issue can be reopened.

[grochocki]

@g-plane / @yatli / @Fabian42 / @ssylvan Feel free to reactivate this issue and update the top comment based on guidance outlined in our new feature process.