Programmer mode on Calculator supports unsigned values

[MicrosoftIssueBot]

Problem Statement Programmers need to work with both signed and unsigned values. Calculator is currently optimized for signed values only.

Evidence or User Insights For example, while calculator will works on INT64 numbers, if I try to paste in a UINT64 value, e.g. 18403114778001080163, it shows as invalid input. Also, currently, the Bit Flip pane only supports signed numbers (the most significant bit is the Sign bit). Unsigned number support is a gap in our programmer mode.

For example, "256" does not fit into a single byte (requires a word):

Proposal Add support for unsigned values in programmer mode.

Goals

• Support both signed and unsigned values in programmer mode.
• Support the option to switch between working with signed and unsigned values.
• All applicable operations should adapt to signed/unsigned status.
• Ensure that terminology is consistent with standards when referring to types like QWORD, DQORD, WORD, and BYTE (these terms generally refer to the unsigned versions).

Non-Goals

• None

Low-Fidelity Concept

Requested Assignment I'm just suggesting this idea. I don't want to implement it.

[MicrosoftIssueBot]

This is your friendly Microsoft Issue Bot. I created this issue automatically as requested by a team member.

[ghost]

This pitch looks like it has everything it needs for review. In the meantime, we'll 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.

[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. I am moving this issue into planning to iron out some of those details and I created calculator-specs/unsignedInput to track progress. 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.

[eveready1010]

See the 2 possible locations for placement of Signed/Unsigned toggle in the attached image. The current Signed/Unsigned setting should be displayed on the toggle as "Signed" or "Unsigned". Also, if current value is greater (less than) than signed maximum (minimum), then the toggle should be disabled. Once the value is within signed limits, the toggle should re-enable.

[eveready1010]

Then disable the "sign" button if the value is above the max threshold.

[ruedi-gallati]

Unable to work with unsigned BYTE: FFH is shown as -1 I expect this to be a very basic function to work with unsigned data types Not suporting unsigned data types, makes this calculator in PROGRAMMER mode unusable

[robambalu]

Just came here to say its really unfortunate this hasnt been fixed in the past 3 years. I agree it is a serious issue and makes this extremely valuable tool unusable in many situations

[ayende]

Having unsigned would make things a lot better, yes.

[phuclv90]

Having 64-bit unsigned support in calculator would be great. However in the mean time you can use powershell which supports [bigint] for arbitrary-precision numbers and[ulong] which is uint64_t. See Windows calculator for programmers

[phuclv90]

Unable to work with unsigned BYTE: FFH is shown as -1 I expect this to be a very basic function to work with unsigned data types Not suporting unsigned data types, makes this calculator in PROGRAMMER mode unusable

You can simply choose any types larger than the desired type in calculator to do unsigned operations. For example for unsigned bytes then WORD, DWORD and QWORD all work. In case you get signed number due to sign extension simply mask out the high bytes to get the unsigned value. This only fails with unsigned QWORD where you have to use powershell currently. That said, powershell is far more useful for programmers than calculator

[ayende]

I'm usually working with uint64, so that is a really bad limitation.

[ghost]

DWORD is unsigned in Visual Studio C++, so I think "DWORD" (at least) should be changed to "LONG", while it is signed in the calculator.

[wwdok]

Is this not supported yet ?

[ghost]

Maybe I'm wrong, but I think it's not.

El vie, 3 mar 2023 a las 11:03, weida wang @.***>) escribió:

Is this not supported yet ?

— Reply to this email directly, view it on GitHub https://github.com/microsoft/calculator/issues/66#issuecomment-1453274729, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUDHOJROKK2L24AUVDB5WO3W2G6X5ANCNFSM4G2PSVEQ . You are receiving this because you commented.Message ID: @.***>

[cbrngrz]

Looks like 64 bit unsigned ints are still not supported; would be really great if they would be and wanted to +1 this feature.

[denimjeans]

MICROSOFT PLEASE READ: everyone above is asking - as me now - the same. Please enable the stock programmers calculator to work with signed + UNsigned 64bit numbers. This is a very basic function. It was also provided where you can implement it. If you are ignoring peoples suggestions for about 5 years, why are you offering the possibilty to provide suggestions at all?

[JerrickRowe]

It's 2024 now. Please Microsoft! Add uint64 feature to the calculator.

[nlar07400]

Any update on that?

[bp9112001]

This looks like a 2 days project for a small size startup, maybe two months for a mid size company, and now almost already 5 years for MSFT, and ongoing ...

[replaysMike]

This is really frustrating, the calculator is mostly useless without unsigned value support.

[phuclv90]

Having 64-bit unsigned support in calculator would be great. However in the mean time you can use powershell which supports [bigint] for arbitrary-precision numbers and[ulong] which is uint64_t

Nowadays powershell can also do int128/uint128 operations beside uint64 and arbitrary precision. It's much more beneficial to programmers than the calculator. So is python or other scripting languages