Calculator: Incorrect currency ratio equality when low valued unit converted to high valued

[Maharramoff]

Describe the bug
Converter rounds/truncates rate to 4 decimal places, therefore currency ratio of low valued units such iranian rial or indonesian rupiah compared to highly valued units like US dollars displayed incorrectly.

Steps To Reproduce

1. Launch the calculator
2. Open the currency converter
3. Select Iranian rial as first unit and US dollar as second.
4. See today's exchange rate.

Expected behavior
Ideally ratio should be rounded appropriately, not too much and not too little. Basically converters round it to 6 decimals. E.g 1 IRR = 0.000024 USD

Screenshots

Device and Application Information (please complete the following information):

• OS Build: 17763
• Architecture: X64
• Application Version: 10.1812.10048.0

Additional context
Possible solution in:

• https://github.com/Microsoft/calculator/blob/0f615faff93dc11101f6b730ce46c69f5390b94c/src/CalcViewModel/DataLoaders/CurrencyDataLoader.cpp#L42
• https://github.com/Microsoft/calculator/blob/0f615faff93dc11101f6b730ce46c69f5390b94c/src/CalcViewModel/DataLoaders/CurrencyDataLoader.cpp#L281

[rudyhuyn]

Nice found!

What if we do something dynamic like:
step 1 - Use 4 decimals by default
step 2 - Verify that minimum 2 digits are visible
step 3 - If not, add 1 more decimal and go back to step 2

[rudyhuyn]

@Maharramoff I just created a diff, let me know what you think!

[grochocki]

Good catch! I really appreciate your thoroughness when filing this bug.

@rudyhuyn I agree with your proposal to address this:

1 - Use 4 decimals by default
2 - Verify that minimum 2 digits are visible
3 - If not add 1 decimal and go back to 2

[MicrosoftIssueBot]

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

[jlaanstra]

Looks like we used to do 4 and now arbitrarily do 2 for small numbers. I think we should be consistent and either always use 4 or 2 or display all digits.

[blurbusters]

Consistency is not the right tool for this particular job:

1. The big numbers should be Easy Info -- e.g. "0.00" or the most accepted common number of digits (e.g. 2 digits for most currencies) -- whatever cashiers need to do to their job. Using Calc on a Surface at a charity booth that accepts both USD and CAD. Cashiers don't need to know more digits than needed.

2. The tiny number should be Details Info with sufficient enough number of digits to display at least 2 significant digits, even if it requires a large number of digits after the decimal. e.g. "0.000024" -- basically it tells you 1 unit of a currency that it's worth something but less than a penny -- important context that is not quickly answered by "0.00" nor "0.000" since some users get confused by that.

I thereby agree with the earlier @rudyhuyn approach, but perhaps change to 4 meaningful digits (followed by zero trim) for the tiny number.

Much more logical approach matching real-world "need to know" information use cases.

Going back to consistency in this particular case, is a regression, full stop.

The problem is that this original tweak away from consistency (for an excellent good reason) was incomplete because hardcoded-4 does not reveal enough digits in some currency conversions like this one. To fix this, the @rudyhuyn variable-digits tweak solves this closer to the intent of "good reason" away from consistency.

Thus, easy info could stay hardcoded-2 as cash register standard or accounting standard -- and details shall go "a few significant digits visible" as currency infoboard standard regardless of how many digits is needed in order to display all important nonzero digits.

For trailing zeros, having too many zeros after significant digits is a lesser evil than having all zeros. That said, smart trimming is recommended best-practice for improved readability, but only down to minimum length (e.g. 2 digits). So that things like "$0.1000" becomes "$0.10" instead of "$0.1". While "$0.00002450000" becomes "$0.0000245". Devil is in the details, but recommended practice definitely diverges from hardcoded-2 when displaying per-unit-currency numbers in a "1 unit equals X" details section. Also, the currency rule for minimum number of decimal digits displayed on a cash register will vary from country to country, so query the system for that because it ain't always 2.

If consistency is an unavoidable mantra, simply go for algorithm consistency. Get exactly a minimum of 4 significant decimal digits regardless of how many zeros after the decimal point. And then smart-trim according to above rules, for both numbers. Still variable number of digits, but at least you've achieved algorithmic consistency for both top & bottom numbers.

Note: I've worked as an employee for a Canadian bank, working as an app developer. LinkedIn Proof. Mic drop.

[HowardWolosky]

256 has some interesting conversation on this topic as well (as the PR for the Issue). I've locked #256 for the time being so that we can have a single point of discussion until an agreed-upon end-state is found.

[grochocki]

I wanted to revisiting this issue so we can drive to resolution. I _really_ appreciate the detailed explanation @mdrejhon provided both here and in #256, and I think I am convinced that the behavior they suggest is the right path forward here. I am going to try my best to summarize the behavior here (@mdrejhon, please correct me if anything seems off):

• Preserve all digits to left of decimal
• Keep 4 significant decimal digits (small-details-number to balance precision with readability)
• Zero trim, but guarantee at least 2 decimal digits (i.e., "1.0000" becomes "1.00", not "1")

Value | Desired
--|--
12|12.00
12.2321|12.2321
12.232|12.232
12.0000007132|12.00
12.232124|12.2321
0.1231|0.1231
0.0231|0.0231
0.005311|0.005311
0.00014311|0.0001431
0.000064314|0.00006431
0.0000000064314|0.000000006431

I am going to unlock #256 to continue with addressing this.