Calculator ignores commas.

guissmo

Steps to reproduce:
Type 5 + 2,50 in Kagi.
It solves 5 + 250 so the answer is 255.

Expected behavior:
The answer should be 7,50.
In Europe the comma is used to separate euros from cents.

Debug info:
I legit cannot see the Debug Info on the desktop version. I'm probably blind. I don't think they're so relevant either.
To contrast, what might be relevant is that my country/region is France but my interface language is English.

DanielVPT

Apparently, Kagi does not recognize the comma (,), however the period (.) can be used.

guissmo

This is not done.

1,50 + 1,50

gives the set {1, 51, 50} instead of 3.

Vlad

guissmo how do you propose we solve for this? perhaps setting for defining decimal point? never saw a search engine do that but we might need to?

guissmo

I don't know the full feature set you have but I would reckon assume don't assume something with commas is a set unless there are curly braces around it?

Google answers 3.

Bing, while it does not directly answer it in its calculator, gives a quick answer suggestion of 3 to 1,50 + 1,50.

Duck Duck Go answers 3.

It's only Wolfram Alpha that parses 1,50 + 1,50 as a set.
On the other hand 1,234 + 1,234 is not treated as a set by Wolfram Alpha.
I could only guess it's because it's based in America and they don't realize the European interpretation?

If I have to make a suggestion (assume W, X, Y, Z are 1-digit numbers)

Anything of the form X,Y and X,YZ : the comma would be treated as a decimal point.
Anything of the form W,XYZ : the comma would be treated as a period separator (separating thousands, millions, billions, etc).
Anything of the form W, X or W,X,Y (note the space after the comma) treat it as a set -- if you really prefer to have a set.

tschoesi

guissmo

Anything of the form X,Y and X,YZ : the comma would be treated as a decimal point.
Anything of the form W,XYZ : the comma would be treated as a period separator

That doesn't make any sense. What if you have a decimal with 3 digits after the point/comma?

The meaning of a comma depends on the region.

guissmo

tschoesi I think claiming the suggestion doesn’t make sense when the proposed solution just misses an edge case is excessive.

I’d like to clarify that when I said “If I had to give a solution”, I meant that this is my best effort at solving the problem within the amount of time I wanted to invest.

While I do voluntarily come here and give feedback and try to give best effort solutions, I feel like it’s not my job to take the time in eke out of all the edge cases of a feature request especially when I’m paying for the service.

frin

I would just like to suggest two changes to above rules:

handle the thousand separator/decimal separator based on user's selected region, you can "reparse" this before sending it off to Wolfram Alpha for simple arithmetics
if there are only digits, commas and calculation symbols present, don’t handle them as sets: +-/*^(), sets should only ever be triggered by {}[]

tschoesi

guissmo

I think claiming the suggestion doesn’t make sense when the proposed solution just misses an edge case is excessive.

I don't believe this is an edge case. Your proposed solution is to infer the meaning of a comma from the number of digits that come after it. Which in my opinion doesn't make sense - the number of digits holds no information about what a comma means.

I feel like it’s not my job to take the time in eke out of all the edge cases of a feature request especially when I’m paying for the service.

Agree. I'm simply pointing out that I don't think your proposed solution would work well in practice. (I agree with your bug report, and I also want it solved.)

In the end it is up to the Kagi team to decide what they think works best.