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.

[ssylvan]

I don't think I can reactivate the issue (at least I don't see an option to do so), but I'll reiterate: if you are printing incorrect results, then that is a bug. Fixing bugs is not "a feature". There may be many ways of fixing this bug (e.g. either print with parenthesis or evaluate after each operator), but that doesn't change the fact that a calculator that explicitly tells its users that 5+5*5=50 is buggy.

[g-plane]

This issue was closed by @grochocki not by me, so I'm not able to reopen.

[grochocki]

Oops--reopening so we can evolve the idea.

[Fabian42]

We can also not edit reports, only the reporter can (and maybe the repository owner or something like that?).

…

On Fri, 8 Mar 2019, 09:59 Dave Grochocki, ***@***.***> wrote: Reopened #138 <#138>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#138 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ_vYqwIbneRg7YeNSPosE9y37i6xsfzks5vUiaHgaJpZM4biQjp> .

[MicrosoftIssueBot]

This is your friendly Microsoft Issue Bot. I've seen this issue come in and have gone to tell a human about it.

[rudyhuyn]

I worked last night on a Diff to add parenthesis to the History panel when using the Standard mode, but if it clears the confusion, in fact, it makes the history harder to read when we display:

((((2 + 3) x 2) + 5) x 4) x 2).

So I trashed my diff, and thought about a new way: display keys instead of operators:

I think it helps a lot and clears the confusion. It's a big refactoring, so before I start working on it, what do you think about this idea?

[g-plane]

Parenthesis should be added when needed.

[ssylvan]

Honestly I think the best thing to fix this is to make it work like those physical calculator (which appears to be the intent for the standard mode). I.e. add a line in the history for each operation (and its result), just like you would get on the "paper roll" on the old physical ones. Makes it very clear that the next operator takes the previous result as an input.

[fwcd]

Parentheses when needed seem to me like a good compromise between readability and correctness:

((2 + 3) x 2 + 5) x 4 x 2

[ssylvan]

Yeah.. The only danger with parenthesis is that it could get very "lispy" if you do a lot of precedence changes back and forth. But it would fix the actual bug (which is that the calculator prints things that are mathematically untrue) and maybe someone can work on a nicer presentation or whatever later to make it clear er why that's the order that was used.

[andrewstellman]

Had a quick back-and-forth with @JeGentle on Twitter about this. Maybe a simple color change could help make this more visually obvious without affecting the behavior of the calculator at all, and without overcomplicating things. Here's a simple mock-up.

[Fabian42]

That highlights "220 x 0.5", which is exactly what did not happen. This reply sounds more reasonable: https://twitter.com/BrandonLive/status/1281604102632296455
That would just highlight "x 0.5" then. Alternatively, the calulation so far could collapse to its result. So when you enter "230-220", you see "230-220" at the top and "10" at the bottom, then when you hit ×, the top becomes "10×" (maybe with a nice animation) and the output stays "10", then when you type "0.5", the top is "10×0.5" and the output "5", everything correct and hopefully somewhat clear.
(BTW, why "x" instead of "×" or "·"?)

[andrewstellman]

It's actually a complex and subtle UX problem, and like I said on the Twitter thread, it would take some experimentation. It's really easy to go down a rabbit hole of overdesigning a solution to this problem.

Yes, your proposed solution makes sense when there are just two terms—and yes, everyone who's seen this problem thought of it, too 😉—but it's problematic. Adding intermediate results, animations, etc., works fine with three terms (230 − 220 × 0.5), but the meaning gets really muddled when once you have a string of terms.

I attached an updated mockup (which now uses × and ÷ instead of x and / since you asked) that shows a longer expression. Try adding intermediate results between all of the terms and it quickly devolves into a visual mess. Adding intermediate terms to the calculation log contorts its meaning, changing it from "this is a record of what you typed" to "this is what the calculator is thinking," which really gets away from the original intention of the standard mode.

That's why I like visually fading all but the last two terms: it highlights that the last two terms are important without altering the semantics of the UI. In effect, it says, "These two terms are the important ones," without changing the overall meaning of that part of the interface. And it keeps the last two terms un-faded as you type in more terms, which reinforces the idea that those are the important part of the expression.

It's still not an awesome solution, and I'm sure it can be improved on, but I think it's a step in the right direction.

[michael-hawker]

Actually just thinking, what if it put the whole old thing in brackets:

(Maybe it could put parenthesis in whenever it needs to so if you evaluated the expression in BEDMAS mode it'd still evaluate to the same answer?)

[andrewstellman]

That's a really interesting idea! It keeps the semantics intact while still being arithmetically correct. Nice!

[grochocki]

Great conversation here! A couple things to consider:

• I think we would have to add a lot of nested parenthesis to gurantee we are showing "how the calculator is thinking" in this mode:

  • With just the one pair of parenthesis, we would actually still be conveying the "wrong" result:
    
  • I think we would have to do this (in the worst case) to get the "correct" answer of -332.5, but this feels really noisy and hard-to-read:
    

• We also have to communicate the "right" thing in history.

  Today, we populate a history item after the user hits =. This works great in all of the other calculator modes, since the other modes do not operate in immediate-execution. In Standard Calculator, every time you perform an operation, it is effectively a soft =.

  Instead of attempting to add parentheses, which could quickly become very visually complex, we would like to explore making each of those soft = equivalent to a hard =. That is, we ensure that history items are added for each transaction that is made, instead of waiting for the user to hit =. This transactional history ensures that we are never showing an "invalid" expression that fails to follow order of operations.

  Effectively, it could look like this, where we always show the "running total" in the input area, and then show the each operation in history.:
  

[Lemmingh]

Excuse me, is it possible to change the name of this mode now before making decisions on other parts?

IMHO, the name “Standard Calculator” is a major cause of confusion, and “Immediate Calculator” proposed by @tngreene sounds like a nice choice.

In the context of calculation, “standard” refers to mathematical principles by default. However, what “Standard Calculator” shows is not math expression but type record, that's, “Standard Calculator” is not a standard calculator.

“Immediate” indicates its nature: Every time you perform an operation, it is effectively a soft =, and you get the result of what you just typed immediately. Even if users can't understand “immediate”, they will pay much more attention when using this mode.

Besides, translating “immediate” is easy to my knowledge.

[I-Campbell]

maybe an improvement of the history side view.

I agree that the simple history (just above the answer) should only show at most the one operator and two operands.

[Lemmingh]

@I-Campbell
maybe an improvement of the history side view.

I'm afraid it's technically not possible, which involves typography, layout and localization at least.

Users may type something complex

For example, how to represent

123456789+1000000000000000√x²1/x-123456789

Meanwhile, don't forget that the width of the History Panel is approximately only 320 epx now. Or if it becomes flexible, given that the width of a UWP app window usually varies from hundreds to thousands of epx, how do you handle it?

Such a view is a tough graphical problem

The design you proposed is a kind of pretty math typesetting which is known to be difficult even in mature LaTeX compiler.

Then, how to implement it with UWP XAML controls? Off the top of my head:

Since we cannot know what a user will type within a sequence, we have to regenerate the History Panel entirely (not just update a few elements), which might be a potential performance problem.

If the History view is a plaintext area, it's a common case that rendering engine surprises you, and even monospaced font is not monospaced, especially when there are multiple scripts. We eventually need to learn from Windows Terminal which succeeds in making all the glyph widths fixed.

If the History view is constructed with pure UWP controls, perhaps it's a grid view. And Character Map UWP tells us that large grid impacts performance significantly on low-end devices.

Maybe other ways ...

Finally, the task becomes as complex as developing a big video game.

The world doesn't use a unified system

If I recall correctly, Arabic people prefer a special math notation system in pretty math typesetting.

We have to consult experts to make every detail correct.

[DenverCoder1]

Over a year later, this is still an issue. I also discovered this issue when I noticed Windows was giving misleading answers to my calculations. The way it displays the calculation, it misleads users into thinking it calculates with order of operations. I now mainly use Scientific Mode since it does not have this issue.

Sidenote: I'm not sure that there really is a need for a calculator that performs operations one at a time (generally it is used with only 1 operator repeatedly and when it's not, you can use parenthesis or use the result in a separate calculation). Almost all calculator applications on any OS use order of operations.

Assuming Windows is to keep this method of calculation for Standard mode, here is my suggestion for a less misleading UI:

The operators can be aligned with the number they are operating on instead of being centered. That way, the user can read it as (((2*3)+2)*5) without the need for cluttering the UI with parenthesis. By grouping the operator and number together, it makes it seem like it is a single operation and they are done one at a time.

[mollyd16]

Hey everyone,

Expanded on @joseartrivera spec.

Let me know what you think!

Feature Pitch Link: microsoft/calculator-specs#27

[MovGP0]

I guess this will totally confuse users: