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 698400 - Improve gnome-calculator back-end
Improve gnome-calculator back-end
Status: RESOLVED FIXED
Product: gnome-calculator
Classification: Core
Component: general
3.8.x
Other Linux
: Normal major
: ---
Assigned To: gcalctool maintainers
gcalctool maintainers
: 714990 (view as bug list)
Depends on:
Blocks: 611970 650944 694864 696986 702817 725319 728179 728657
 
 
Reported: 2013-04-19 20:16 UTC by PioneerAxon
Modified: 2014-12-22 20:49 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description PioneerAxon 2013-04-19 20:16:17 UTC
The current calculation back-end of gnome-calculator (MP code) is outdated and not well optimized.
It was initially coded in Fortran, then converted to C, and then to Vala. Therefore it doesn't take the advantages of the functionality in newer languages in the ways it could.

Moreover the community doesn't understand the code well, which makes it harder to maintain and to resolve bugs in that code. This also limits the possible significant digits the gnome-calculator can generate.

The solution can be to make the Number's dynamically allocated based on calculation or to use an external library like GNU's MP or MPFR library (as pointed out by Santiago Saavedra on IRC discussion).
Comment 1 Santiago Saavedra 2013-04-20 00:18:59 UTC
Besides, the current back-end is used just for this project, which means less eyes looking at bugs there (and there are a couple already reported).

I believe that externalizing the back-end calculus to a well-known and used Multiple Precision arithmetic library could reduce the mantainment effort here.

For those reasons, IMHO, we shouldn't reinvent the wheel in the backend, but use good foundations already used for that.

Also, I propose to allow different backends: at least one for fixed point numbers and another for floating point ones.
Having different internal representations for each kind would make calculations take much less space and have more significant digits.

This would mean making Number an abstract class and extending it.
Comment 2 André Klapper 2013-04-20 08:48:00 UTC
(Not blocking development -> resetting bug severity.)

What exactly needs to happen that would make this bug report fixed?
"Improve X" style bug reports always feel vague to me and unfixable, if they are not actionable and do not consist of well-defined subtasks.
Comment 3 PioneerAxon 2013-04-20 09:32:20 UTC
This bug is blocking the 4 bugs listed below..

The back-end needs to be replaced with the GNU MP & MPFR libraries in order to fix this bug..

This is part of this year's Google summer of code program. Hence it is reported to make the discussion, submission and review easier..

The list of subtasks are not mentioned at the moment as the students will have to list them as a part of their application..
Comment 4 Santiago Saavedra 2013-04-30 22:55:30 UTC
My proposal is listed publicly at http://www.google-melange.com/gsoc/proposal/review/google/gsoc2013/ssaavedra/1

There's a mirror of the HTML at https://gist.github.com/ssaavedra/5471621
Comment 5 Michael Catanzaro 2013-11-22 03:00:11 UTC
*** Bug 714990 has been marked as a duplicate of this bug. ***
Comment 6 PioneerAxon 2014-12-22 20:49:39 UTC
The issue has been fixed.

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