After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 694864 - Doing too large of a calculation results in '0' with no error shown
Doing too large of a calculation results in '0' with no error shown
Status: RESOLVED FIXED
Product: gnome-calculator
Classification: Core
Component: general
3.7.x
Other Linux
: Normal normal
: ---
Assigned To: gcalctool maintainers
gcalctool maintainers
Depends on: 698400
Blocks:
 
 
Reported: 2013-02-28 12:56 UTC by Jeremy Bicha
Modified: 2014-12-22 20:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Displays error for very large power calculation instead of zero. (1.15 KB, patch)
2014-02-16 12:37 UTC, elita astrid angelina lobo
none Details | Review
Corrected patch: Displays error for very large power calculation instead of zero. (791 bytes, patch)
2014-02-18 08:58 UTC, elita astrid angelina lobo
none Details | Review
bitwise instead of arithmetic operator (1.17 KB, patch)
2014-02-23 08:15 UTC, Abhinav
rejected Details | Review
fix for calculation of large powers and large factorials and also ln(e^x) gving error for x>3 (503 bytes, patch)
2014-02-27 10:57 UTC, elita astrid angelina lobo
reviewed Details | Review
This patch removed the while(true) , remove break , remove >> and made the code more readable. (878 bytes, patch)
2014-03-06 15:17 UTC, Abhinav
rejected Details | Review

Description Jeremy Bicha 2013-02-28 12:56:34 UTC
gnome-calculator 3.7.90 on Ubuntu 13.04 amd64.

Entering 2²²²² results in 0 with no error displayed.

For certain calculations I get the error 'Overflow: the result couldn't be calculated' so this error should at least be shown here.

It looks like the limit is somewhere around 2^1342 (or 9*10^403).

With gcalctool 6.6.2, although it takes a while to calculate, I still get results from 2 squared 7 times (which is 3*10^688955) which is a significantly higher limit.
Comment 1 Abhinav 2014-02-14 18:36:41 UTC
Is 2^2^2^2^2 equivalent to 2^256 = 1.157920892×10⁷⁷ ???
Comment 2 Abhinav 2014-02-14 18:42:54 UTC
Sorry, 
2^2^2^2^2 equivalent to 2^65536 ?
Comment 3 elita astrid angelina lobo 2014-02-16 12:37:22 UTC
Created attachment 269295 [details] [review]
Displays error for very large power calculation instead of zero.

As stated by the reporter , it seems that 2^1342 is the limit of of Power Calculation.
This patch displays error "Power Calculation out of range" when x is raised to a very high power y instead of zero.Kindly review the patch let me know if this patch could be a possible solution for this bug. Thankyou.
Comment 4 elita astrid angelina lobo 2014-02-18 08:58:08 UTC
Created attachment 269513 [details] [review]
Corrected patch: Displays error for very large power calculation instead of zero.

This patch displays error for very large power calculation instead of zero considering the fact that 2^1342 is the limit of power calculations.
Comment 5 PioneerAxon 2014-02-22 19:28:59 UTC
Review of attachment 269513 [details] [review]:

Thank you for the patch.

I don't think this is the best way to fix this issue.
A better way to fix this would be to detect an overflow while calculating the value, and set the error.
Comment 6 Abhinav 2014-02-23 08:15:50 UTC
Created attachment 270043 [details] [review]
bitwise instead of arithmetic operator

This patch wont solve the bug but I think it will slightly speed up the process . 
if ((n&1) == 1)  instead of n%2 == 1  and n>>=1 instead of n=n/2
Comment 7 PioneerAxon 2014-02-23 21:16:20 UTC
Review of attachment 270043 [details] [review]:

Thank you for the patch.

I don't think this will help the execution speed much, as most of these optimizations are already being done by the underlying C compiler.

Second thing is that the code readability is really important. So, changing these statements is not a good choice.

::: number_org.vala
@@ -913,8 +913,0 @@
-        /* 0^0 is indeterminate */
-        if (is_zero () && n == 0)
-        {
... 5 more ...

First of all, why are you trying to revert someone else's changes?
You should check the diff before committing and before submitting the patch.
Comment 8 Abhinav 2014-02-24 03:32:34 UTC
ok  . Thank you . Will do diff properly  .
Comment 9 elita astrid angelina lobo 2014-02-27 10:57:31 UTC
Created attachment 270458 [details] [review]
fix for calculation of large powers and large factorials and also ln(e^x) gving error for x>3

Although this patch fixes the 3 issues mentioned above , I haven't substituted the if condition by any other condition to check overflow as I am not very sure in which case the if condition was supposed to be applicable. Kindly let me know the exact application of the if condition so that I can make the required changes in the patch. Thankyou.
Comment 10 elita astrid angelina lobo 2014-02-27 14:06:20 UTC
Also I apologize for the above patch being quite incomplete and perhaps  directly removing a part of the code without substituting it with any other code is not allowed. Hence if this patch with some modification could possibly be a fix for the three bugs , I would like to work on it.
Comment 11 Abhinav 2014-03-06 15:17:03 UTC
Created attachment 271114 [details] [review]
This patch removed the while(true) , remove break , remove >> and made the code more readable.

The patch that I have submitted improves readabilty without affecting the work speed or flow of the gnome calculator  .
Comment 12 PioneerAxon 2014-03-19 14:08:15 UTC
Review of attachment 270458 [details] [review]:

The patch doesn't fix the actual problem, and might end up crashing the Calculator.

This bug will be automatically fixed when we replace the back-end of Calculator, as it is directly related to how the overflow is detected and how the calculations are performed.
Comment 13 PioneerAxon 2014-03-19 14:35:13 UTC
Review of attachment 271114 [details] [review]:

The patch neither fixes the issue, nor is it related to the bug.
Comment 14 PioneerAxon 2014-12-22 20:26:52 UTC
Jeremy,

Thank you for th report.
The bug has been fixed in master branch. Now you can either get the correct result, or a message saying "Precision error".

Also, the back-end is capable of calculating numbers upto 2²⁰¹⁹.

However, if more precision is needed, the fix is as simple as increasing the back-end precision value using dconf. It will slow down calculations, but if you gotta have more precision, you gotta pay the cost.. :P


Reference commit : https://git.gnome.org/browse/gnome-calculator/commit/?id=0e863eeb121d670d8f5266a82b6152e98b2428ea

Hope this helps..