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