From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Rounding to even for numeric data type |
Date: | 2015-03-27 23:26:24 |
Message-ID: | 32725.1427498784@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
> It sounds appealing to switch the default behavior to something that
> is more IEEE-compliant, and not only for scale == 0. Now one can argue
> as well that changing the default is risky for existing applications,
> or the other way around that other RDBMs (?) are more compliant than
> us for their equivalent numeric data type, and people get confused
> when switching to Postgres.
> An idea, from Dean, would be to have a new specific version for
> round() able to do compliant IEEE rounding to even as well...
I think confining the change to round() would be a fundamental error.
The main reason why round-to-nearest-even is IEEE standard is that it
reduces error accumulation over long chains of calculations, such as
in numeric's power and trig functions; if we go to the trouble of
implementing such a behavior, we certainly want to use it there.
I think the concern over backwards compatibility here is probably
overblown; but if we're sufficiently worried about it, a possible
compromise is to invent a numeric_rounding_mode GUC, so that people
could get back the old behavior if they really care.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Arthur Silva | 2015-03-28 03:53:16 | Re: GSoC 2015: SP-GIST for geometrical objects |
Previous Message | Andreas Karlsson | 2015-03-27 23:14:50 | Re: Index-only scans with btree_gist |