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 541500 - Numbers with >15 digits inaccurately displayed
Numbers with >15 digits inaccurately displayed
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: Analytics
1.6.x
Other All
: Normal normal
: ---
Assigned To: Morten Welinder
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2008-07-04 07:09 UTC by Keith G. Robertson-Turner
Modified: 2008-07-09 15:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Keith G. Robertson-Turner 2008-07-04 07:09:15 UTC
Please describe the problem:
29513736 * 92842033 = 2740115251665280 (according to Gnumeric)

Correct answer = 2740115251665288

Steps to reproduce:
1. A1 = 29513736
2. A2 = 92842033
3. A3 = A1*A2


Actual results:
Wrong answer given (2740115251665280)

Expected results:
The right answer (2740115251665288)

Does this happen every time?
Yes

Other information:
Gnome Calc, oocalc, bc, etc. all produce the correct answer.
Comment 1 Morten Welinder 2008-07-04 13:22:55 UTC
We were outsmarting ourselves in the 1.6 series.  1.8.x is fine.
Comment 2 Morten Welinder 2008-07-09 15:44:13 UTC
For the benefit on anyone from comp.os.linux.advocacy who might wander by,
this bug was actually in goffice and was fixed, if not before, in goffice 0.3.7:

	* Total rewrite of number formatting.

We went from interpreting the format strings to pre-compiling them into
byte-code.  That, in turn, made it possible to do the actual number-to-
string operation using (a variant of) C's sprintf.

If memory serves me right, the problem would affect only numbers with 15 or
more digits.  Note, that not all 15-digits integers can be represented
accurately in the standard C "double" type.  For example, 999999999999999
cannot.  If you need to operate with integers of this scale accurately,
you need to compile with "long double" support.  That should get you up
to 33 digits, depending on hardware platform.