Multiplication bug in calculator when using period instead of comma

[maxtyrin]

Microsoft PowerToys version

0.61.1

Running as admin

• Yes

Area(s) with issue?

PowerToys Run

Steps to reproduce

Alt Space to run PowerToys Run
Enter: 6700 * 0.03

✔️ Expected Behavior

The result would be 201

❌ Actual Behavior

PowerToys returns 2010, probably because of the period usage in place of comma.
6700*0.03 = 2010
6700*0,03 = 201
I think it's a bug because 6700*0.1 returns correct answer, but going lower doesn't

Other Software

No response

[Jay-o-Way]

Hello and thanks for your message. What are your (Windows) regional settings? And there's a check-box in PowerToys Settings dealing with regional format (. or ,)
I think the leading zeros - after the decimal - get trimmed off. We've seen this issue before 😟

[maxtyrin]

Hello, thanks for the reply.
Region: Russia, Regional format: Russia (Russia).
Found the checkbox, thanks.
I guess it's a duplicate issue of a leading zero getting trimmed off then. Do I need to close this?

[rgary87]

Hello,
Can confirm, bug still exists: 9.9 * 1.005 = 14.85 and 9.9 * 1.05 = 14.85 too.

PowerRun v0.61.1
Windows regional settings : France , Français (France)
Checkbox in Run settings indeed does fix this: 9.9*1.005=9,9495

Thanks for the info @Jay-o-Way

[Jay-o-Way]

My own results; local decimal is a comma ,:

• Use English notation for input (unchecked)
  =6700*0.03 → 20100 ❌
  =6700*0,03 → 201 ✔
  =9.9*1.005 → 99495 ❌

• Use English notation for input (checked)
  =6700*0.03 → 201 ✔
  =6700*0,03 → 20100 ❌
  =9.9*1.005 → 9,9495 ✔

Looking at this, I think that for the input that is not matching the local delimiter, all the . are simply ignored. 0.03 becomes (00)3.

[kosi2801]

Still happening with 0.64.1 and German region settings.
Very subtle and dangerous issue as a wrong result is presented even in case an incorrect comma-style is used and there is no direct hint to the user that something could be off.

[kosi2801]

Maybe it came too late for 0.65.0, as it's not listed in the "Known Issues" of that release.
But just for protocol, 0.65.0 is still affected by this issue.

For the next release I'd suggest to at least include this unexpected behavior in the list of "Known Issues" if no fix for it can be done by that time.

[Jay-o-Way]

@crutkas @stefansjfw @jaimecbernardo we rrreally need to do something about this

[htcfreek]

My own results; local decimal is a comma ,:

• Use English notation for input (unchecked)
  =6700*0.03 → 20100 ❌
  =6700*0,03 → 201 ✔
  =9.9*1.005 → 99495 ❌

• Use English notation for input (checked)
  =6700*0.03 → 201 ✔
  =6700*0,03 → 20100 ❌
  =9.9*1.005 → 9,9495 ✔

Looking at this, I think that for the input that is not matching the local delimiter, all the . are simply ignored. 0.03 becomes (00)3.

This is exactly how it should work:

• Setting checked: A dot is expected.
• Setting uncheck: The character definded in culture settings of windows is expected.

If you use the wrong delimiter it is interpret as thousand separator instead of decimal separator. And then all trailing zeros are removed because 001 is the same as 1.

[kosi2801]

If you use the wrong delimiter it is interpret as thousand separator instead of decimal separator.

Thanks, with that mention of the thousand separator I finally could understand what's going on. It never even crossed my mind because although I work with numbers on a quite regular basis a thousand-separator is used absolutely never.
Also I now checked where the all those settings are and how they work together.

I understand from a technical perspective that the handling is "correct", but at least from my practical experience this is really unexpected and very confusing (esp. when regularly also switching between english and eg. german formats).

I have no real suggestion how it could be improved for the multi-national userbase of the Run plugin, but for me personally I'd prefer a (default-on) setting to not interpret thousand-separators (whatever it is) at all instead of toggling the meaning of "." and ",".
(So only interpret one of "." or "," but give an error on the other one instead of treating it silently.)

[LapinFou]

This bug is still present in the latest version.

PowerToys v0.68.1
Windows regional settings : France , Français (France)

When I'm using the DOT key on the numpad, this will give a "." instead a ","
The windows regional settings is not taken in account in the entry field of the PowerToysRun.
Fortunately, I enabled "Use US format" calculator option as a workaround.

[Jay-o-Way]

Linking #2265 and #24611

[crutkas]

/dup #2265

[microsoft-github-policy-service]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!