Thread: Rounding strategy
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/13/functions-math.html Description: The 'round' mathematical function documentation doesn't specify its rounding strategy. If this would be documented then users can rely on its rounding behavior. For double precision the rounding probably depends on your platform. For numeric the function seems to round to nearest with ties going away from zero (sometimes referred to as "round half up). 6.5 -> 7.0 and -6.5 -> -7.0.
On Mon, 2021-04-19 at 08:00 +0000, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/13/functions-math.html > Description: > > The 'round' mathematical function documentation doesn't specify its rounding > strategy. If this would be documented then users can rely on its rounding > behavior. For double precision the rounding probably depends on your > platform. For numeric the function seems to round to nearest with ties going > away from zero (sometimes referred to as "round half up). 6.5 -> 7.0 and > -6.5 -> -7.0. +1 Yours, Laurenz Albe
On Mon, 2021-04-19 at 08:00 +0000, PG Doc comments form wrote: > The 'round' mathematical function documentation doesn't specify its rounding > strategy. If this would be documented then users can rely on its rounding > behavior. For double precision the rounding probably depends on your > platform. For numeric the function seems to round to nearest with ties going > away from zero (sometimes referred to as "round half up). 6.5 -> 7.0 and > -6.5 -> -7.0. Here is a proposed patch. Yours, Laurenz Albe
Attachment
Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Mon, 2021-04-19 at 08:00 +0000, PG Doc comments form wrote:
>> The 'round' mathematical function documentation doesn't specify its rounding
>> strategy. If this would be documented then users can rely on its rounding
>> behavior. For double precision the rounding probably depends on your
>> platform. For numeric the function seems to round to nearest with ties going
>> away from zero (sometimes referred to as "round half up). 6.5 -> 7.0 and
>> -6.5 -> -7.0.
> Here is a proposed patch.
LGTM, although I think we can be a bit more specific about the float
case. I suggest
... by rounding away from 0. For <type>double precision</type>,
the tie-breaking behavior is platform dependent, but
<quote>round to nearest even</quote> is the most common rule.
regards, tom lane
On Thu, 2021-04-22 at 13:50 -0400, Tom Lane wrote: > Laurenz Albe <laurenz.albe@cybertec.at> writes: > > On Mon, 2021-04-19 at 08:00 +0000, PG Doc comments form wrote: > > > The 'round' mathematical function documentation doesn't specify its rounding > > > strategy. If this would be documented then users can rely on its rounding > > > behavior. For double precision the rounding probably depends on your > > > platform. For numeric the function seems to round to nearest with ties going > > > away from zero (sometimes referred to as "round half up). 6.5 -> 7.0 and > > > -6.5 -> -7.0. > > > > Here is a proposed patch. > > LGTM, although I think we can be a bit more specific about the float > case. I suggest > > ... by rounding away from 0. For <type>double precision</type>, > the tie-breaking behavior is platform dependent, but > <quote>round to nearest even</quote> is the most common rule. Makes sense. Here is an updated patch. Yours, Laurenz Albe
Attachment
On Fri, 2021-04-23 at 09:40 +0200, Laurenz Albe wrote: > Makes sense. Here is an updated patch. I see that you have already committed your proposed version. Thanks! Yours, Laurenz Albe
Thanks a lot! Cheers, Rudolph On 23-04-2021 10:51, Laurenz Albe wrote: > On Fri, 2021-04-23 at 09:40 +0200, Laurenz Albe wrote: >> Makes sense. Here is an updated patch. > > I see that you have already committed your proposed version. > Thanks! > > Yours, > Laurenz Albe >