Bug 9285

Summary:	round(.5) produces wrong results
Product:	[Retired] Red Hat Linux	Reporter:	Joe Harrington <jhmail>
Component:	gnumeric	Assignee:	Preston Brown <pbrown>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	high	Docs Contact:
Priority:	medium
Version:	6.1	CC:	jhmail, spacewar
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-02-11 17:40:34 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 2000-02-09 22:25:09 UTC

The round() function rounds incorrectly if the number being rounded is
exactly half the digit being rounded to, or an odd multiple thereof.  For
example:

round(.5) is given as 0, whereas round(.50001) is 1

The same happens if the rounding is to several decimal places:
round(.005,2) is 0, but round(.0050001,2) is .01.

Since most of the world rounds .5 to the next larger absolute number (-.5
is rounded to -1), it is important to change this behavior.  Financial
calculations and the assumptions of the federal government in tax form
preparation come to mind, not to mention the behavior of the popular
spreadsheets that share a file format with gnumeric.

Most round() implementations, such as the ones in python and glibc, round
.5 to 1.  Note that guile does not (is guile the engine behind gnumeric?).
In glibc, it is possible to set a rounding mode that is other than the
standard one.  I wonder if this is what was done in gnumeric?  It's
controllled by a #define, not a function argument.

I'm marking this as high priority because tax time is upon us and round()
is used heavily in tax form preparation.

--jh--

Comment 1 Havoc Pennington 2000-02-11 17:40:59 UTC

This is the correct behavior according to the Gnumeric guys,
Excel does it this way as does Visual Basic, and it's some sort
of standard thing that people expect. There may be
another function that does what you want, not sure.

If you want to change it you should file a bug on bugs.gnome.org
asking to make it an option or argue with the Gnumeric guys
on gnumeric-list and talk them into it. Anyway
we don't want to change arguably correct application behavior in the Red Hat
copy of the program, we rely on the upstream maintainers
to be the experts on this.

Comment 2 Joe Harrington 2000-02-11 18:26:59 UTC

Actually, this is incorrect.  In Excel 97, =round(0.5,0) gives 1, as it should.

I will file a report on the Gnome site.

--jh--

Comment 3 Eric Smith 2000-11-14 22:16:04 UTC

I can't run gnumeric at all (bug 18170), but perhaps gnumeric is using IEEE
round-to-even mode.
If you always round numbers that are exactly halfway between rounding values,
e.g., 0.5, 1.5, 2.5, etc.
up, you introduce statistical bias.  So IEEE specified a mode that always rounds
such cases to the
nearest even rounding value.  So 0.5 would round to 0, while 1.5 would round to
2.  Assuming a uniform
distribution of numbers, that rounding mode introduces no statistical bias.