I just noticed that (at least in the trunk version) commas are not
replaced anymore by decimal points in decimal numbers which can lead
to some unexpected results if users are not aware of the fact that
commas are wrong here (in many locales decimal numbers are written
with the comma instead of the point). So, one could e.g. get "3,6 +
1,4 = 3"
What's really calculated here (sorry, didn't bother to look at the
code)? And does the behaviour stay this way?
Regards,
Marco
Thanks for noticing this.
The above expression will yield only "3" because "3,6+1,4" will be
evaluated to "3" only. The first comma (,) makes the rest of the
expression invalid if the chosen decimal point is dot (.).
I guess we should prompt an error message in this case, instead
silently truncate and execute the expression.
Could you kindly file it as a bug so it won't be forgotten?
Regards,
Ariya
I don't know, whether this has been discussed already, but simply
replacing decimal points by commas leads to special problems, because
expression parsers are confused. For instance, if you define functions
with two arguments (e.g. angle(x, y)), and you submit something like
angle(2,3,4), this is ambiguous: Does it mean angle(2.3, 4.0) or
angle(2.0, 3.4). Or is it a three-argument call angle(2.0, 3.0, 4.0)?
Resolving such ambiguities by more refined rules can be difficult and
lead to non-obvious behavior.
Wolf
In SpeedCrunch, function argument separator is actually semicolon, no
matter the locale. So it cannot lead to any ambiguation in this
context, since you are forced to write angle( 2; 3; 4 ).
Wolf