Bug 33101 - round(.5) (still) produces wrong results
Summary: round(.5) (still) produces wrong results
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gnumeric   
(Show other bugs)
Version: 7.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Owen Taylor
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2001-03-24 21:41 UTC by Joe Harrington
Modified: 2008-05-01 15:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-03-26 15:23:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Joe Harrington 2001-03-24 21:41:14 UTC
This bug was incorrectly marked not a bug under RH 6.1, and it persists in
7.0.  The original report is bug 9285.

The problem is that round(0.5) produces 0, but round(1.5) produces 2, and
so on for all the  even and odd half-integers.  This behavior is consistent
regardless of the number of decimal places being rounded to or whether the
number is negative or positive.

Why this is a bug: The gnumeric help manual states "This function is Excel
compatible." in the description of the round() function.  However, Excel
rounds 0.5 to 1 and 1.5 to 2.  So does every other spreadsheet I can find. 
There is a mathematical niceness that is satisfied by the current gnumeric
behavior, but it does not match with what people (other than very technical
users) expect, nor with practical applications such as tax form
preparation.  The US federal and most state forms require rounding
half-integer values to the next higher integer, if rounding is used at
all.  At this point, I cannot use gnumeric to do my taxes because it is not
possible to program it to produce correct results.

The original bug report included some speculations for where the error
could be occurring, including modes set by the glibc library call. 
Regardless, this bug should be fixed immediately.  At the very least, the
claim that the function is Excel compatible should be removed until the
problem is fixed.  It would be acceptable, and a good idea, to provide the
current behavior in a function with a different name, such as

If the decision is made not to fix the bug, please state why.  The previous
resolution came after an explanation that was demonstrably incorrect: Excel
does not work this way.


Comment 1 Owen Taylor 2001-03-27 22:13:08 UTC
These questions really should be addressed upstream as recommended in Havoc's
original response (bugzilla.gnome.org, gnumeric-list), since Red Hat does not
maintain the package. But I investigated this some more and found:

 - gnumeric never (to my knowledge) implemented round-to-even - it
   always tried to implement round-up like excel.
 - versions of gnumeric older than 0.62 may appeared to not due
   this due to the limits of floating point precision. (0.015 does
   not have a precise representation as a float, but is rather
   represented as something like 0.0149999, so rounding 0.015
   produces 0.01, not 0.02 as you expected.)
 - new versions of gnumeric have some tweaks to the floor/ceiling
   code to try to produce the "expected" result rather than 
   the mathematically correct result at edge cases.
 - This has nothing to do with IEEE rounding modes.
 - I suspect the IRS has bigger worries than how you round the 
   pennies on your return. (All versions of gnumeric should
   round the dollars correctly, since half integers have
   exact representations as float point numbers.)

Thanks for the report. (I'm marking this as resolved Rawhide,
since it is fixed upstream, though we don't actually have 
a sufficiently new version in Rawhide to fix this. You can
get a newer version by compiling from sources, or probably
from getting the gnumeric package from www.ximian.com.)

Note You need to log in before you can comment on or make changes to this bug.