Bug 33101

Summary:	round(.5) (still) produces wrong results
Product:	[Retired] Red Hat Linux	Reporter:	Joe Harrington <jhmail>
Component:	gnumeric	Assignee:	Owen Taylor <otaylor>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0	CC:	jhmail
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-03-26 15:23:44 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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
roundbalanced().

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.

--jh--

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.)