Bug 9285 - round(.5) produces wrong results
Summary: round(.5) produces wrong results
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gnumeric
Version: 6.1
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Preston Brown
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-02-09 22:25 UTC by Joe Harrington
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-02-11 17:40:34 UTC
Embargoed:


Attachments (Terms of Use)

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.



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