Calculator not calculating correctly when using more than a single digit after decimal point

[AlphaVision]

Microsoft PowerToys version

0.68.0

Installation method

PowerToys auto-update

Running as admin

No

Area(s) with issue?

PowerToys Run

Steps to reproduce

When multiplying a number by another with a single digit (i.e. 0.3) after the decimal point all works ok, but when trying to multiply by a smaller number (i.e. 0.003) all zeroes after the decimal point are ignored and the results shown is as if a single trailing digit number was used.

✔️ Expected Behavior

To calculate small floating point numbers i.e. 0.0004

❌ Actual Behavior

The zeroes after the decimal point are ignored and the number is converted to 0.4

Other Software

No response

[Jay-o-Way]

Linking #2265. @crutkas @jaimecbernardo @htcfreek we need a fix for this asap. Don't want any buildings crashing down because PowerToys is responsible for bad calculations, or anything like that...

[jaimecbernardo]

@Jay-o-Way , perhaps we should make the "Use English (United States) number format for input" the default, since it seems that's how people expect it? 🤔

[Jay-o-Way]

@jaimecbernardo it's not about the decimal character. converts the fractional part into a number and the leading zero's get trimmed off.

[htcfreek]

@jaimecbernardo it's not about the decimal character. There is a fault in the Mages which converts the fractional part into a number and the leading zero's get trimmed off.

@Jay-o-Way
Is there an existing issue on the mages repo? If not we should open one that they can fix the bug.

[Jay-o-Way]

@jaimecbernardo and @htcfreek - we have been discussing this exact issue literally for years now. My commment above (blaming Mages engine) wasn't correct. See, Jaime, you explicitly mentioned the cause in #12375 (july 2021)

Every 0 after the dot on my comma-decimal system configurations seems to be ignored.
1.449*51.0000006 gives the same result (74,7684).
Even 1.0000449*51.0000006 gives the same result (74,7684).

I see that we're also translating the numbers between cultures 🤔 May be this is where the issue is.

I can confirm. Basically we're trying to translate numbers between cultures but then removing leading zeroes...

At the time I thought it was a bug in the engine. Now as I tried it again trying to prevent wrong inputs being sent to the engine I noticed that we're doing some number culture translation, and that's where this comes from. In this translation numbers like 59.06 are seen as two different numbers when . is not the decimal separator. So the numbers 59 and 06 are translated individually and replaced in the query, meaning 59.6 is passed to the engine.

[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!