GNOME Bugzilla – Bug 611970
Calculations incorrect with large numbers
Last modified: 2014-12-22 20:33:38 UTC
When meets big numbers, Gcaltool 5.29.92 returns wrong answer. For example, "888!": When I use python, it returns 257365811240746258261058312635496048130210642911052728912405050489847845936124604455726245537138568519919138869993820540619317156386110281318043523819271133040245050833530381384223242463725798006902411731729593770548785690354781086905842723308884801601200379052751917433951594795069246539623889566172402612394273813442913138634455511343892185394277862364138060724692422176326391957764020447386941437446725478761545107390817405634196802572153899519689487073825003215226617854722625058758294222344083356593753257086354039728300782461317497535062225687078681424411893621525850551269343434971126659954733715916782958472453656768810440701195867642664276246868388275821267618720767840980999383693936888759532254366317019814634072835535528238339276696529590492607088777154869458497157498973960649754315551943201432369267509169588502957749960541697921095814304037256642324456938413254625533153280856940717899783245778945051168906015433910286854807561451501938458959243234283134088179776468080393516478163145085578656974388367221108095677627567015952254146171246437988038149150987707167315073537790062736939314320210458720139105535344696345447770657457362031933212587185848613853398987903918414682644458052794592851305410955768885474260613862805460079057807727238845021832356538307021541713160320875576539401590159447926998635089309190781896462345990784880322764271663904123377742519178473040194012177227689415411742481696796207548195180131422419383028352271214484900120165291146804072489789248793346781239796284546531818941890571677176899236847462415968281683926928007538265304095422178343439306412724651705340187355911592282977060598094755781754218900772740050037966772213112296704368289348866131536557227203591833504468255928529993693686570881138553294753614798339407527326181492069008868558254336122129801882121115421377833709324088258996044105013303675033524073942148782155553588617920517036672360857955988473054416496830250418320295432036884294666305652837013806869131833276398423114995974063714689045182764541217341440000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000. But gcaltool returns 25736581124074625826105831263549604813021064291105272891240505048984784593612460445572624553713856851991913886999382054061931715638611028131804352381927113304024505083353038138422324246372579800690241173172959377053910000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000.
*** Bug 613805 has been marked as a duplicate of this bug. ***
*** Bug 581289 has been marked as a duplicate of this bug. ***
Summarising examples from duplicate bug reports: 888! (2^705) mod 3 (2^705)! 6^6^6^6
*** Bug 587669 has been marked as a duplicate of this bug. ***
Why this serious bug is still not fixed?
Because the problem is very low down in the MP (math code). It's complicated code that's very old and has been converted from Fortran. Unfortunately none of the developers know it well enough. Patches welcome!
(In reply to comment #6) > Because the problem is very low down in the MP (math code). It's complicated > code that's very old and has been converted from Fortran. Unfortunately none > of the developers know it well enough. Patches welcome! Fine. I'll have a try.
(In reply to comment #6) > Because the problem is very low down in the MP (math code). It's complicated > code that's very old and has been converted from Fortran. Unfortunately none > of the developers know it well enough. Patches welcome! You said "This wrong result is due to memory corruption as can be show with valgrind.", could you give me some more infomation? thanks.
I just tried it then, and valgrind is not showing any error messages anymore. So the problem is not due to memory corruption, but probably the numbers internally overflowing.
Okay... Thanks.
That's got to be related to the declaration internally of long and integer since there is a limit to which you can go before which it will overflow, shouldn't it?
This might help. However, I am not aware of any consequences (except for visible difference time requirements). It basically adds more round of iterations in mp_multiply_real() in mp.c. I will dig deeper, if this solves your problem. These things happens and will happen because of size limitations in MPNumber structure. So more sensible solution is to either make a new MP library or to tweak the current one to balance it for time and space complexity against false outputs. diff --git a/src/mp-private.h b/src/mp-private.h index 3211ea8..a255b2a 100644 --- a/src/mp-private.h +++ b/src/mp-private.h @@ -28,7 +28,7 @@ // mperr("MP_SIZE TOO SMALL IN CALL TO MPSET, INCREASE MP_SIZE AND DIMENSIONS OF MP ARRAYS TO AT LEAST %d ***", MP.t); // MP.t = MP_SIZE; //} -#define MP_T 100 +#define MP_T 800 void mperr(const char *format, ...) __attribute__((format(printf, 1, 2))); void mp_gcd(int64_t *, int64_t *);
Xhacker Liu, Thanks for the bug report. The issue has been fixed in master branch. Now Calculator will either generate correct answer or show "Precision error". The back-end uses a GSettings to have a configurable precision, which is pre-set to optimal performance for most use-cases at this point. If you require more digits (at cost of computation time), you can modify the value using dconf. Reference commit : https://git.gnome.org/browse/gnome-calculator/commit/?id=0e863eeb121d670d8f5266a82b6152e98b2428ea Hope this helps.. :)