Ticket #326 (Fixed)Wed Nov 14 09:27:29 UTC 2012
SciCalc uses the local decimal separator in calculations
| Reported by: | Dick Tanis (1648) | Severity: | Normal |
| Part: | RISC OS: Application | Release: | |
| Milestone: | Status | Fixed |
Details by Dick Tanis (1648):
It’s nice that SciCalc uses the configured Territory to represents the number in the local format but it also uses this representation to perform the calculations. This works fine when the separator is a dot but here in the Netherlands where it’s a comma it doesn’t (everything after the , is ignored). This gives very strange results for example. 2 times 1.2 gives 1 instead of 2.4. Also when the window has input focus the dot on the numeric keyboard doesn’t work, it inputs nothing.
Changelog:
Modified by Dick Tanis (1648) Wed, November 14 2012 - 20:21:10 GMT
The unary operators work correctly but the operators with 2 operands (+ – / x) are the trouble makers. Did some debugging and found out that the Real variables n1, n2 of function FNcalc_contains numbers with a comma when I enter real number. So if I enter 2,4 × 3,5 and report STR$n1 STR$n2 via the reporter module I get 2,4 and 3,3. How is this possible? How can a Real variable in BASIC contain a comma? If I assign A=5,5 I get the mistake error. How is this possible?
Modified by Dick Tanis (1648) Thu, November 15 2012 - 00:03:51 GMT
Find out why this bug occurs. I know understand why a real could give result strings with a comma. This depends how the variable @% (set representation format for PRINT) has been set. In SciCalc this is the case: @%="+G10"+DecimalPoint$+"10" in PROC calc_init. As it starts with a + this means that STR$ are also affected.
Now look at line answer=(STR$n1+opp$+STR$n2) in FNcalc_evaluate(n1,opp$,n2). Here it goes wrong when the decimal separation char is not a dot. Because STR$ are used, values like 5.4 are converted to their local format (in Dutch 5,4) which that EVAL will drop everything after the comma.
The quickest solution is localizing @% and setting it to +G10.10 in FNcalc_evaluate. Also in PROCwimp_init this must be done because the procedure uses STR$ to verify if BASIC64 is loaded. Which means that if the decimal is something awkward (like a !) the comparison fails even if the program runs in BASIC64.
Another solution is removing the first + in @%="+G10"+DecimalPoint$+"10". I tried that but then the summary bar give sometimes other results (rounding errors) than the display.
Modified by Chris (121) Sun, December 16 2012 - 11:16:31 GMT
Dick: I made a few small tweaks to SciCalc recently, and added this fix. It seems to work here when DecimalPoint$ is a comma. Could you send me an email to cdwraight at yahoo dot co dot uk, and I’ll send you a copy to test? If all works as it should, I’ll submit a fixed version to ROOL.
Modified by Sprow (202) Sat, May 18 2013 - 20:06:29 GMT
- Status changed from Open to Fixed
Chris’ changes in SciCalc-0_78
