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 752839 - General format rendering of 8.37 for very wide case
General format rendering of 8.37 for very wide case
Status: RESOLVED FIXED
Product: libgoffice
Classification: Other
Component: General
GIT
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2015-07-24 18:45 UTC by gnome.maz
Modified: 2015-08-18 12:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
round display bug (2.04 KB, application/x-gnumeric)
2015-07-24 18:45 UTC, gnome.maz
Details

Description gnome.maz 2015-07-24 18:45:13 UTC
Created attachment 308098 [details]
round display bug

Hi

I've come accross a strange bug with the round function displaying much more decimals than expected.
Tested on Archlinux 64 with gnumeric 1.12.22.

The first column 1, 2, 3 4, …
The second column is :
=round(-log10(power(0.3,$A1)),2)

At 17 and 18, it bugs and displays far more than 2 decimals. However, there is a catch, the column has to be resized wide enough. Otherwise, all seems to work ok.

On Linux Mint 17.1 with gnumeric 1.12.9 it has the bug also.
Comment 1 Andreas J. Guelzow 2015-07-24 23:54:09 UTC
The ROUND function has nothing to do with how many decimals are displaced. You would do that either with the cell format or the text function, e.g. =text(-log10(power(0.3,$A1)),"0.00").

ROUND changes the value to the closest representable value to the number obtained by rounding to two decimals.

See http://www.gnumeric.org/numerical-issues.html
Comment 2 Morten Welinder 2015-07-25 10:24:33 UTC
Although as Andreas says, using the formatting is the right thing
to do for controlling display, this is a bug.

However, it doesn't look like round is at fault.  =837/100 produces
the same long result, but we're supposed to pick the shortest string
that has the right value.  That would suggest a problem in go_dtoa.
Comment 3 Morten Welinder 2015-07-25 19:23:10 UTC
Not go_dtoa.  It gets told to render a certain precision and does that.
If told get render the shortest representation it delivers "8.37".

go_render_general is current suspect.
Comment 4 Morten Welinder 2015-07-27 00:06:12 UTC
This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.
Comment 5 gnome.maz 2015-07-30 15:31:04 UTC
While it is harder to reproduce the bug it still exists on 0.10.23.

The width of the column has to be precisely adjusted to contain 8.36999999999.
Too large or too small and it displays 8.37.

If I copy paste special only value, I can also trigger the bug. If I directly enter 8.37, it also bugs.

On my screen, I have to set the width to 139 pixels (140.25 point).

The header always shows 8.37.
Comment 7 Morten Welinder 2015-08-18 12:09:28 UTC
Believed fixed.