Re: [HACKERS] Rounding to even for numeric data type

Michael Paquier writes: > On Sat, May 2, 2015 at 9:53 PM, Fabien COELHO wrote: >> Quick review: patches applies, make check is fine, all is well. > Thanks for the feedback, Fabien! >> All the casting tests could be put in "numeric.sql", as there are all >> related to numeric and that would avoid

Re: [HACKERS] Rounding to even for numeric data type

v2 applied & tested. [...] Not sure about that, the tests are placed here to be consistent with for is done for float8. Maybe float8 to numeric casts could have been in numeric too. [...] I reworked the example in the docs. Indeed, looks good. -- Fabien. -- Sent via pgsql-hackers maili

Re: [HACKERS] Rounding to even for numeric data type

On Sat, May 2, 2015 at 9:53 PM, Fabien COELHO wrote: > Quick review: patches applies, make check is fine, all is well. Thanks for the feedback, Fabien! > All the casting tests could be put in "numeric.sql", as there are all > related to numeric and that would avoid duplicating the values lists.

Re: [HACKERS] Rounding to even for numeric data type

So, attached is a patch that does 1) and 2) to make clear to the user how numeric and double precision behave regarding rounding. I am adding it to CF 2015-06 to keep track of it... Quick review: patches applies, make check is fine, all is well. Two minor suggestions: All the casting tests c

Re: [HACKERS] Rounding to even for numeric data type

Dean Rasheed wrote, On 2015-03-28 10:01: > On 28 March 2015 at 05:16, Andrew Gierth wrote: >>> "Tom" == Tom Lane writes: >> >> Tom> I think the concern over backwards compatibility here is probably >> Tom> overblown; but if we're sufficiently worried about it, a possible >> Tom> compromise

Re: [HACKERS] Rounding to even for numeric data type

On Wed, Apr 22, 2015 at 9:30 PM, Pedro Gimeno wrote: > Dean Rasheed wrote, On 2015-03-28 10:01: >> On 28 March 2015 at 05:16, Andrew Gierth wrote: "Tom" == Tom Lane writes: >>> >>> Tom> I think the concern over backwards compatibility here is probably >>> Tom> overblown; but if we're

Re: [HACKERS] Rounding to even for numeric data type

Michael Paquier wrote: > Well, I am not sure about that... But reading this thread changing the > default rounding sounds unwelcome. So it may be better to just put in > words the rounding method used now in the docs, with perhaps a mention > that this is not completely in-line with the SQL spec if

Re: [HACKERS] Rounding to even for numeric data type

On Mon, Mar 30, 2015 at 4:51 AM, James Cloos wrote: >> "MP" == Michael Paquier writes: > > MP> So, attached is a patch that does 1) and 2) to make clear to the > MP> user how numeric and double precision behave regarding rounding. > MP> I am adding it to CF 2015-06 to keep track of it... > >

Re: [HACKERS] Rounding to even for numeric data type

> "MP" == Michael Paquier writes: MP> So, attached is a patch that does 1) and 2) to make clear to the MP> user how numeric and double precision behave regarding rounding. MP> I am adding it to CF 2015-06 to keep track of it... Given that the examples show -2.5 rounds to -3, the IEEE term is

Re: [HACKERS] Rounding to even for numeric data type

On Sun, Mar 29, 2015 at 7:59 AM, Michael Paquier wrote: > On Sun, Mar 29, 2015 at 5:34 AM, Gavin Flower > wrote: >> On 28/03/15 21:58, Dean Rasheed wrote: >> [...] >>> >>> >>> Andrew mentioned that there have been complaints from people doing >>> calculations with monetary data that we don't impl

Re: [HACKERS] Rounding to even for numeric data type

On Sun, Mar 29, 2015 at 9:21 AM, Gavin Flower wrote: > On 29/03/15 13:07, David G. Johnston wrote: >> >> On Sat, Mar 28, 2015 at 3:59 PM, Michael Paquier >> mailto:michael.paqu...@gmail.com>>wrote: >> >> On Sun, Mar 29, 2015 at 5:34 AM, Gavin Flower >> >

Re: [HACKERS] Rounding to even for numeric data type

On 29/03/15 13:07, David G. Johnston wrote: On Sat, Mar 28, 2015 at 3:59 PM, Michael Paquier mailto:michael.paqu...@gmail.com>>wrote: On Sun, Mar 29, 2015 at 5:34 AM, Gavin Flower mailto:gavinflo...@archidevsys.co.nz>> wrote: > On 28/03/15 21:58, Dean Rasheed wrote: > [...]

Re: [HACKERS] Rounding to even for numeric data type

On Sat, Mar 28, 2015 at 3:59 PM, Michael Paquier wrote: > On Sun, Mar 29, 2015 at 5:34 AM, Gavin Flower > wrote: > > On 28/03/15 21:58, Dean Rasheed wrote: > > [...] > >> > >> > >> Andrew mentioned that there have been complaints from people doing > >> calculations with monetary data that we don

Re: [HACKERS] Rounding to even for numeric data type

On Sun, Mar 29, 2015 at 5:34 AM, Gavin Flower wrote: > On 28/03/15 21:58, Dean Rasheed wrote: > [...] >> >> >> Andrew mentioned that there have been complaints from people doing >> calculations with monetary data that we don't implement >> round-to-nearest-even (Banker's) rounding. It's actually t

Re: [HACKERS] Rounding to even for numeric data type

On 28/03/15 21:58, Dean Rasheed wrote: [...] Andrew mentioned that there have been complaints from people doing calculations with monetary data that we don't implement round-to-nearest-even (Banker's) rounding. It's actually the case that various different financial calculations demand different

Re: [HACKERS] Rounding to even for numeric data type

Dean Rasheed 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 mor

Re: [HACKERS] Rounding to even for numeric data type

On Sat, Mar 28, 2015 at 5:58 PM, Dean Rasheed wrote: > On 27 March 2015 at 23:26, Tom Lane wrote: >> 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

Re: [HACKERS] Rounding to even for numeric data type

On 28 March 2015 at 05:16, Andrew Gierth wrote: >> "Tom" == Tom Lane writes: > > Tom> I think the concern over backwards compatibility here is probably > Tom> overblown; but if we're sufficiently worried about it, a possible > Tom> compromise is to invent a numeric_rounding_mode GUC, so th

Re: [HACKERS] Rounding to even for numeric data type

On 27 March 2015 at 23:26, Tom Lane wrote: > Michael Paquier 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

Re: [HACKERS] Rounding to even for numeric data type

> "Tom" == Tom Lane writes: Tom> I think the concern over backwards compatibility here is probably Tom> overblown; but if we're sufficiently worried about it, a possible Tom> compromise is to invent a numeric_rounding_mode GUC, so that Tom> people could get back the old behavior if they r

Re: [HACKERS] Rounding to even for numeric data type

Michael Paquier 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 co

[HACKERS] Rounding to even for numeric data type

Hi all, A couple of days ago a bug has showed up regarding rounding of float here: http://www.postgresql.org/message-id/flat/20150320194337.2573.72...@wrigleys.postgresql.org#20150320194337.2573.72...@wrigleys.postgresql.org The result being that the version of rint() shipped in src/port was not I