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