Should the program:
1. just show an error message saying "hey, you locale's decimal
separator is a comma/dot, use it instead"
2. automatically correct the expression
3. just drop it all and allow the user to enter either comma or dot,
even mixed in an expression?
4. yet another choice
Thank you.
What do you think is the most wise action for SpeedCrunch to take
after the comma/dot issue? (see
http://code.google.com/p/speedcrunch/issues/detail?id=51&can=2&q= )?
Should the program:
1. just show an error message saying "hey, you locale's decimal
separator is a comma/dot, use it instead"
2. automatically correct the expression
3. just drop it all and allow the user to enter either comma or dot,
even mixed in an expression?
4. yet another choice
In my locale, the decimal separator is a comma. However, I tend to write
lots of things in English, so sometimes I use dots as decimal separator. As
long as the comma/dot is used consistently in the expression, I don't see a
reason for showing an error, it should just work. "1,4+3,6" should
return "5" regardless of the locale's decimal separator, "1,4+3.6" should
give some kind of "decimal separator mismatch" error.
--
Henrique Pinto
taw...@gmail.com
Wolf Lammen
Maybe a combination of both?
The expression is corrected, but at the same we show friendly warning
(only once in each session) that it contains possibly wrong decimal
point.
The problem with (2) only is the user is not aware that he's doing
something "wrong".
Regards,
Ariya
This is fortunately already implemented (see the configuration
dialog). In fact, it's one of the commonly requested features.
The problem is not having the option for choosing the decimal point
(which we have already), rather what to do when spurious character is
found and it's possibly because the user is using "wrong" decimal
point than what he intentionally sets.
Regards,
Ariya
I'd go for this one. As the comma and dot cannot be used in another
function in the grammar (that would be truly confusing) I don't see a
reason for not accepting both. This means accepting both characters,
even mixed in the same expression. IMHO there is no real risk for
ambiguity. The only scenario would be if someone decided to use the
comma as a thousands separator writing 12,345.67 - but that would lead
to a parsing error (to decimal separators in one number). Writing
12,345 would probably confuse such a user, but who uses thousands
separators in calculators?
As for output, I'd suggest that we go for the LOCALE.
Having an option to pick the separator would, IMHO, be overkill.
There is no need to be able to tweak everything - and if you want to
tweak it, do it in your system settings.
/J
People working on business and/or financial system often use 12,345
and 12,345.67 forms. Imagine if they copy and paste some figures, do
some calculation, and the result is that they're poorer by some
thousands.
Of course, no disclaimer for using SpeedCrunch and they should
double-check everything, but the point remains. That's why I tend not
to like automatic handling and making the program too smart. It's like
doing something what it is not told to do.
> Having an option to pick the separator would, IMHO, be overkill.
> There is no need to be able to tweak everything - and if you want to
> tweak it, do it in your system settings.
Yes, but that option is only for convenience, e.g. your locale states
comma and you want to copy-paste some expressions from your scientific
English scratch pad.
And don't forget, on some locked-down system, it's not always possible
to change the locale settings (needs admin access, etc).
Regards,
Ariya