Don't clear input when switching modes

[Diggsey]

Problem Statement
Often I need to use functions from both programmer and scientific modes in the same calculation, but if I switch modes it loses my input. When the input is representable in both modes there is no reason to clear it.

Evidence or User Insights
No other calculator does this, and there's no need for the input to be cleared. There's a button to clear the input.

Proposal
Preserve the value when it is within the domain of the target mode, otherwise show an error in the display area.

Goals
Remove the annoyance of losing the value when you switch modes.

Non-Goals
Settle on a unified representation of values such that separate "modes" are not even necessary.

[MicrosoftIssueBot]

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

[dgendreau]

Agreed. I believe the Windows 7 calculator kept the current value when switching modes and this has always been an annoyance for me with the w10 calculator.

[grochocki]

Thanks for submitting your idea! Let's keep this idea open for discussion so the community has the chance to provide feedback. Check out our New Feedback Process for more info on the user-centered process we follow for new feature development.

[rba100]

Might be good to think of the use case for switching modes, just in case the problem can be solved another way. For me, the use case is to see the hex or binary representation of a number having got there from scientific, which is generally my default mode because it supports the power and log keyboard shortcuts. Personally, I think persisting the values (and truncating if necessary) between modes is a sensible thing to do in any case.

[ygoe]

@dgendreau AFAIR the Windows 7 calculator didn't have the separate scientific and programmer modes in the first place. Dec/hex view was possible in the same view as 1/x. So there was no need to switch modes. When I first saw the Windows 10 calculator, I immediately felt like I wanted back the Windows 7 calculator. By now, I somehow came to an arrangement with it, but I'm not really happy with that experience.

To Microsoft: My telemetry data (I only learned through this GitHub project that the calculator has that!) should have told you that already. Not sure you heard it because nothing has changed.

[seanofw]

I can't second this feature request enough. My use case for this feature is a bit different from @rba100's; so here's my "Agile user story," if you like developing software around such things:

As a software engineer, I often work on many projects throughout a day. While I often need Scientific mode to calculate a bunch of statistics with one team, an hour later I'll then need Programmer mode to perform a bunch hex/decimal conversions with another team — and there's nothing more annoying than typing in a number (and sometimes even doing an operation or two on it) and then realizing you're in a mode that doesn't support the operations you need on it. If I'm smart, I'll remember to copy it to the clipboard (or to Notepad) before switching; otherwise, I'll have to type it in again, and if I've already done some operations on it, it then becomes a game of trying to remember "What did I do before?" So please update Calculator so that it won't lose my data because, just like a USB plug's orientation, it always starts the wrong way, no matter which way it starts.

[dodexahedron]

Might be good to think of the use case for switching modes, just in case the problem can be solved another way. For me, the use case is to see the hex or binary representation of a number having got there from scientific, which is generally my default mode because it supports the power and log keyboard shortcuts. Personally, I think persisting the values (and truncating if necessary) between modes is a sensible thing to do in any case.

Honestly, in addition to not clearing state, I think you stumbled across a better solution right here: Just let us use the full range of operators in programmer mode, instead of restricting us to a) bitwise operators and b) whole numbers.

Heck... That gives me another idea... It can show us integers as bit vectors. How about IEEE754?
Perhaps worth another issue if it hasn't already been proposed...

[Pharap]

@ygoe

The Windows 8 calculator definitely has separate programmer and scientific modes.
I think it's the same as the Windows 7 calculator, but I could be wrong.

(I agree with preferring it over the Win10 calculator.)

[ygoe]

Oh, you're right. I just looked up some screenshots in the Google image search. Win7 has the same modes. It was Windows XP's calculator that had the base selection in the same view as the scientific functions. Good old times, long ago.

[ghost]

We reviewed the pitch and would love to explore this idea further! The pitch is a great start, but there are still some open questions. Moving this into planning to iron out some of those details. A human will follow up with some feedback on your pitch shortly. Keep in mind that not all ideas that make it into the planning phase are guaranteed to make it to release. For more information on next steps, check out our spec workflow.

[grochocki]

The idea is mostly captured by the content of the pitch, but we think there are a couple more details to figure out, since different modes support different sets of functionality (e.g., what happens when you switch from Programmer calculator with HEX output to Standard calculator?). I created calculator-specs/keepInputOnModeSwitch to track progress.

[dodexahedron]

The idea is mostly captured by the content of the pitch, but we think there are a couple more details to figure out, since different modes support different sets of functionality (e.g., what happens when you switch from Programmer calculator with HEX output to Standard calculator?). I created calculator-specs/keepInputOnModeSwitch to track progress.

Well...
Why does it have to be one or the other?
In other words, why can’t scientific mode support hex, binary, etc, as well?
In windows do, you used to be able to, for example, carry out the following sequence of events:

1. Enter a number in hex in dev mode
2. Left shift
3. Change to scientific, keeping the current input
4. Perform other operations only available in scientific mode
5. Switch back to dev mode to turn the number back into hex

I guess this boils down to one quintessential question:
Why are scientific and programmer modes even separate, at all, rather than just additional display panels for, eg, the binary display?

[ygoe]

Switching from dev mode to scientific mode while in hex display? Where's the problem? There is a value, it can be represented as decimal, hex, base-12 or whatever base. If scientific mode only displays decimal, then that's what it'll do. Is there anything that can't be computed here? Of course it would be nice if switching back to dev mode would remember the previously selected base.

Switching from scientific mode to dev mode that only supports integer numbers? Then round the number. There's a greater question here since there are three different ways to round a number.

[grochocki]

Why are scientific and programmer modes even separate, at all, rather than just additional display panels for, eg, the binary display?

Fair question. Keep in mind, though, that there are many different types of users. Would an average user (non-developer) find value in having support for binary/HEX values, bitwise operators, and other developer-centric functionality in other modes? Might it cause confusion?

Switching from dev mode to scientific mode while in hex display? Where's the problem? There is a value, it can be represented as decimal, hex, base-12 or whatever base. If scientific mode only displays decimal, then that's what it'll do.

This seems like a reasonable approach.

Switching from scientific mode to dev mode that only supports integer numbers? Then round the number. There's a greater question here since there are three different ways to round a number.

This is exactly why we felt like this feature could benefit from a a more detailed plan. It is intended to capture the desired behavior for all of these transitions.

[ygoe]

Wait, four ways to round a number: (1) The mathematical, (2) always up, (3) always down, and (4) the one that .NET uses (mathematical but .5 goes down every so often only to confuse people).

[seanofw]

There are more, @ygoe, at least ten rounding modes that I can think of offhand. @grochocki is right that this isn't as obvious as it might seem.

Simplistic rounding modes:

• All fractions toward zero (i.e., truncation).
• All fractions away from zero (i.e., absolute ceiling).
• All fractions toward +infinity (always up, i.e., ceil()).
• All fractions toward -infinity (always down, i.e., floor()).

The many variations on "nearest" rounding:

• Toward nearest integer, but 0.5 values always toward zero (i.e., midpoint truncation).
• Toward nearest integer, but 0.5 values always away from zero (i.e., midpoint absolute ceiling).
• Toward nearest integer, but 0.5 values always toward +infinity (i.e., midpoint ceiling). (This is the mode you get if you take floor(x + 0.5).)
• Toward nearest integer, but 0.5 values always toward -infinity (i.e., midpoint flooring). (This is what you get if you take ceil(x - 0.5).)
• Toward nearest integer, but 0.5 values use banker's rounding toward even (0.5 rounds down, 1.5 rounds up, 2.5 rounds down, 3.5 rounds up, etc.). (I believe this is what VB and .NET use.)
• Toward nearest integer, but 0.5 values use banker's rounding toward odd (0.5 rounds up,1.5 rounds down, 2.5 rounds up, 3.5 rounds down, etc.).

The two "banker's rounding" modes are an attempt to distribute rounding errors at 0.5 evenly across the number line, and are useful for money (see also: plot of Office Space) and for certain statistical calculations.

---

For my part, I'd propose either truncate (all fractions toward zero) or floor (all fractions toward -infinity) when converting from a rational-value mode to an integer-only mode. Programmers in languages like C++ and C# and Java typically expect that when you have a float x and you cast it to int you get the equivalent of floor(); so if we assume that "Programmer's Mode" exists for programmers to use, then the digit-dropping behavior they're used to is the behavior they'd likely expect. Whether you pick truncate or floor might be a subject of debate, but it only affects negative values, which are usually less-often-used in programmer modes anyway.

That said, you could just as easily bury a radio button in the menus somewhere to control the rounding mode, but I think the likelihood is low that a programmer usually wants anything except truncate or floor, so I'd recommend not coding a feature that a lot of people aren't clamoring for.

[p0358]

Worst case scenario, until rounding strategy is decided, it could just move all round numbers over (including all numbers from programmer mode to any other) and just don't move over values with commas. This would still be much better than not moving over any values at all!

And imo truncate approach would be the best there, and the most expected in most cases. Or if people are uncertain, it could be added as a configurable option, though I don't believe it's worth increasing the complexity.

[al-n]

Hi there,

what is the current status of this item? Just came accross this because I cleared my input accidentally while switching from Standard to scientific mode and being very unhappy and wanting to change something ;)

As I am completely new to Windows Calculator Development: What would the next steps be for this to be implemented? Happy to help with any sort of planning or coding, but I guess I need a bit help for a starting point...

Is it that we should gather the specs of the proposal in https://github.com/microsoft/calculator-specs/tree/keepInputOnModeSwitch? Cause I cannot see anything in there, so at least copying the part that was agreed upon here could be a start.

The main point added in discussion was the question of how to round values -- but this question can also be solved in a genereic way at least through an implementation that leaves space for future adjustemts as well as for doing rounding according to some setting in the app... So actually development could start if it can handle the rounding question in a sufficiently generic way...?

[p0358]

Yeah, seriously, this is a shame that this is still open and unresolved, for almost 2 years soon.
I repeatedly keep finding this a problem in day to day use...

[igadmg]

Omg. So much discussion for such a simple and useful feature, and no progress in 5 years.

[p0358]

Yep, that's Microsoft for ya. Seen exact same thing with one feature request in vscode. I even forgot about this one right here. Personally I've switched to using Python prompt and just doing maths there, less annoying