Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> Sure, using round-to-nearest-even for intermediate rounding in
> complex numeric methods would be a good way to reduce (but not
> completely eliminate) rounding errors. But that's a somewhat
> different proposition from changing the default for round(),
> which is a much more user-visible change. If we did implement a
> choice of rounding modes, I would still argue for keeping
> round-half-away-from-zero as the default mode for round().
I'm inclined to agree. In business software development, that's
how I've seen the "stakeholder" expectations. Thinking back, I can
remember dealing with rounding in manufacturing incentive pay
calculation, interfacing long-range demand forcasting to production
planning, interfacing engineers' CAD/CAM software to IBM MAPICS,
professionals' timekeeping/billing/AR systems, and various general
accounting software systems; and as I seem to remember those
efforts, round half away from zero has always been when end users
understood and expected when explicitly rounding a final result.
I understand how rounding half to even in intermediate results
minimizes rounding error, and would not be surprised to see some
users with different expectations, but there is clearly a large
base of people who would be surprised by it when rounding a final
result.
> I also agree with Andrew that all numeric functions should be
> kept immutable.
Which means no GUC should affect how it behaves, although a
function with a parameter to control rounding behavior would be OK.
It kinda seems like the SQL round() function should have a
parameter to control this which defaults to the historical behavior
when omitted.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company