Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 9285 - round(.5) produces wrong results
round(.5) produces wrong results
Product: Red Hat Linux
Classification: Retired
Component: gnumeric (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Preston Brown
Depends On:
  Show dependency treegraph
Reported: 2000-02-09 17:25 EST by Joe Harrington
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-02-11 12:40:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joe Harrington 2000-02-09 17:25:09 EST
The round() function rounds incorrectly if the number being rounded is
exactly half the digit being rounded to, or an odd multiple thereof.  For

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.

Comment 1 Havoc Pennington 2000-02-11 12:40:59 EST
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@gnome.org 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 13:26:59 EST
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.

Comment 3 Eric Smith 2000-11-14 17:16:04 EST
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.