Dean Rasheed <dean.a.rash...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
