Re: Rounding to even for numeric data type - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Rounding to even for numeric data type
Date
Msg-id 32725.1427498784@sss.pgh.pa.us
Whole thread Raw
In response to Rounding to even for numeric data type  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Rounding to even for numeric data type  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Re: Rounding to even for numeric data type  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-hackers
Michael Paquier <michael.paquier@gmail.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



pgsql-hackers by date:

Previous
From: Andreas Karlsson
Date:
Subject: Re: Index-only scans with btree_gist
Next
From: Arthur Silva
Date:
Subject: Re: GSoC 2015: SP-GIST for geometrical objects