GNOME Bugzilla – Bug 317378
Exponential notation bug
Last modified: 2006-01-05 12:46:51 UTC
Please describe the problem: The exponential notation E is an engineering shorthand for (x10^). So for example a number 4300 may be abbreviated as 4.3E3 E therefore binds tightly to the number and therefore should be parsed during computation as (4.3x10^3) and not as 4.3x10^3 This becomes important in a computation such as this 4300/2300 in abbreviated form it would read 4.3E3/2.3E3. In the current gcalctool implementation E is automatically expanded inline as x10^ this leads to the erroneous setup 4.3x10^3/2.3x10^3 which is equivalent to 4.3x10^3x10^3/2.3 != 4300/2300 not at all what was intended. The fix is to not implement the expansion of E inline as x10^ but to write a separate routine to handle the occurrence of E. This error persists in all versions up to the most recent one. Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information: Reported by Jibie Job <jibie dor job at gmail dot com>
Comment from Sami: I think your result is caused by the fact that MPstr_to_num() does not process correctly xe+y or xe-y numbers. Try 4 . 3 Exp 3 = Result is 4.44 Try 2 . 3 Exp 3 = Result is 2.44 Now, 4.44 / 2.44 = 1.819672131, which explains the result. If it is not possible to fix MPstr_to_num() I can try make parser to understand xe+y form and calculate it instead of tokeniser understanding xe+y as a number and giving it to MPstr_to_num().
Passing this back to Sami. I think the problem needs to be solved in the parser. I say this because the following works just fine in non-arithmetic operator precedence mode: ((4.3e3)/(2.3e3)) where "e" is clicking on the Exp button. You should be able to solve this without needing changes to MPstr_to_num().
*** Bug 317538 has been marked as a duplicate of this bug. ***
Created attachment 53432 [details] Fix for the problem.
Sami provided a patch which appears to fix this. I've checked the changes into CVS HEAD and bumped the version number in configure.in to 5.7.8. I'll probably generate a compressed tarball to and announce in on gnome-announce.
Came across this problem, (in 5.6.31) eg 40GBytes/(12MB/sec) duration=40EXP9/12EXP6=3333333333333333.33 secs (~~105M days :-( Looks like it was doing 40/12*10^9*10^6. With 5.7.18, the result is 3333.33 repeating. (~~55 minutes ;-) I can hence confirm it is fixed for at least the above test case. Excellent guys!