Decimal separator confusion - in default setting, both comma and dot end with no error but produce different output

[Anna Piekarska]

Operating system: linux debian testing, with Polish language (where comma is default separator) Speedcrunch version: 0.12

Steps to reproduce:

• Enter 1,0 and hit enter - result is 1

• Enter 1.0 and hit enter - result is 10

In some previous version, entering 1.0 would result in an error. Later (I think in 0.11) both 1,0 and 1.0 would give 1. With current behavior, speedcrunch silently ignores the dot. This, combined with the previous, could produce lots of unwanted mistakes.

I have found the setting that sets both comma and dot as a decimal point, but before I found it I made several mistakes due to the change. I think the default setting should match the behavior of the previous version.

[Helder Correia]

Hi @apiekarska. You have a good point. However, I also see the current behavior in 0.12 as the correct one. System default should really take into consideration the locale's radix character and digit grouping separator. I've been dealing with this separator confusion for a decade now. People from different parts of the world expect different behaviors. On every release, I try to "fix" it based on complaints, only to get new complaints from the "other side". It is hard and frustrating to handle this and try to please everyone, but sometimes I just don't know what to do, TBH. There really should be one single separator defined by ISO, but it is unfortunately not the case.

[Tey']

About dot character being ignored by default in your locale: please note that dot and comma are both used as decimal and thousand separators. Typically, in countries where one of these characters is used as a decimal separator, the other one is used as a thousand separator. SpeedCrunch just ignores thousand separators, that's why the dot character is ignored.

We might use a different style for thousand and/or decimal separators so that users can find out there is something unexpected going on. But dot and comma characters are so small that I'm not sure we could find an efficient style for that. Maybe underlining thousand separators could do the trick (the same way spell checkers underline errors), with a hover tooltip indicating the character will be ignored?

[Helder Correia]

Something like that, @Teyut . Or playing with syntax highlighting.

[Tey']

Yes, I was indeed thinking of doing that during the syntax highlighting step. But right now, it only sets characters colors and I don't think this will be enough to notice small characters like dot and comma.

[Anna Piekarska]

Thank you for your answers. I understand that everyone wants it their way and I found that there is a choice for the user, which I think is the best way to handle that.

I have raised this issue because the previous behavior was to treat both separators as a decimal point and I wasn't aware of the change after updating. This resulted in some incorrect calculations before I realized what is going on. So the main point I think are not my preferences but the confusion that may lead to unnoticed errors.

I think the most safe option would be to show syntax error for the other separator by default and possibly (but not necessarily) tell the user that this can be now adjusted in options menu.