Kiss: Using dots as decimal points to do math from the search bar yields incorrect results

[Dakkaron]

Describe the bug
I use a phone with austrian locale. In this locale the comma character is used as a decimal seperator. If I use dots instead, the calculator seems to work but gives wrong results.

To Reproduce
Steps to reproduce the behavior:

1. Use Austrian locale on your phone
2. Enter: 0.1+0.2
3. Result is 3

When using the comma character (,) everything works fine.

Expected behavior
I would like it to work the same way, regardless of whether I use commas or dots.

So possibly, replace one with the other before passing it to the maths parser.

Additional information

• App version: 3.13.0
• App installed via: (f-droid, Play Store, debug APK): Debug

Additional context
Add any other context about the problem here.

[TBog]

In this locale the comma character is used as a decimal seperator

Use a different locale or abide by the rules of the locale, why did you label this as a bug?

[Neamar]

@TBog I do think this is a bug.

Using english as a locale, you can type "0,1+0,2" and get 3.

Both of those behaviors are incorrect.
We should either treat this as an error, or deal with this properly.

[Dakkaron]

I also think so. Either stick strictly to the locale (so "0,1" or "0.1" respectively should be treated as not a number) or better normalize the input so that "," and "." mean the same regardless of locale.

The main problem with the current situation is that you could input a calculation and the output will be wrong, but maybe not wrong enough for you to notice.

In the end, @TBog , you are right. It is an user input error. But due to lacking input validation/correction this is an error that is not easily visible.

I would much prefer if "," and "." are normalized so that it means the same, because there isn't really any meaning to "," in the English locale or "." in e.g. the Austrian locale. So you would not loose anything by normalizing.

The reccomendation to switch locales is not a good solution. First, it does not remedy the problem, just moves it to a different character (now "," does not work anymore instead of "."). Second, changing locale has a lot more effects on other apps and the OS than just changing what you can input into the search bar. I'd rather not use the calcuation feature of KISS than change my locale.

[Neamar]

So... this is actually fairly tricky, because of the "grouping" separator.
Basically, some languages like to do stupid things with their separator, for instance in English "1,000.00" is valid and means "one thousand". Same for "1,000". But in Austrian, "1,000" is also valid, but means "1".
It gets tricky because the grouping can be anywhere. So "0,1" in English is "1" -- it's just a leading, unused zero, and then the number.
So there is no easy way to know what's happening. We can't simply replace all commas with dots, as that would lead to other invalid results.

And we can't throw an error, because those numbers are actually valid.

So.... not sure what do do. Starting to understand @TBog's point :p

[TBog]

Maybe we should print the parsed formula to let the user understand what is going on.

This is just weird 🤪

[Neamar]

Agreed. Although I think in your case above it should crash since there can't be multiple decimal separator :(

[Dakkaron]

I had a look at what other calculators do, and most of the ones I found don't allow the grouping separator to be entered at all.

The Windows calculator ignores the grouping separator (e.g. pressing the "." key on Austrian locale does nothing at all).

The Android calculator (I used an external keyboard for that) and the "Old Calculator for Windows 10" both interpret both characters as a decimal point.

The calculator integrated in Google search (you get to it by searching for "calculator") takes both characters as decimal points. It further ignores locale by always displaying the decimal point as ".", no matter what the locale says.

All of these calculators add the group separators automatically in the input/result fields as pure markup, so they aren't characters that the user can interact with.

Using the Google search bar as a calculator is plain weird. There both characters are used as decimal point, unless you use the grouping separator to demark 1000s. So (in Austrian locale) "1.1+2 = 3.1", but "1.001+2 = 1003".

Wolfram Alpha ignores locales and uses the US locale regardless. Here the user can enter a "," as a group separator, but only allow it to demark 1000s. So "1,000 = 1000", but "10,00" or even "1,00,0" is not a number.

All phyiscal calculators that I have ever seen only support decimal point and don't allow the user to input group separators. Most of them add the separators automatically.

I wonder what's the benefit of entering group separators. Or even, if any user would actually enter group separators.

TBog's suggestion to at least show the parsed string would help a lot. Because then at least the user would get a fitting feedback on

[saveman71]

I agree for treating both , and . as decimal points and not "caring" further for the locale. As @Dakkaron described this is the most common and logic behavior. I'm convinced that the "Google search bar" behavior you describe is a bug :smile:

[Dakkaron]

Oh, another little inconsistency: grouping separators after a decimal point go through the parser, but just discard everything after the separator:

(in Austrian locale):
1,1.1+2 = 2.1

I am making a pull request to fix all this.