Thread: Explanation of the ROUND function with NUMERIC as an argument
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/15/bug-reporting.html Description: I think the manual's description of the round function with numeric as an argument is different from the actual behavior. manual https://www.postgresql.org/docs/15/functions-math.html Explanation of the manual's ROUND function round ( numeric ) → numeric round ( double precision ) → double precision Rounds to nearest integer. For numeric, ties are broken by rounding away from zero. For double precision, the tie-breaking behavior is platform dependent, but “round to nearest even” is the most common rule. round(42.4) → 42 Operation of the ROUND function postgres=# SELECT round(CAST(42.5 AS numeric)); round ------- 43 (1 row) I am thinking that the value of the ROUND function with NUMERIC as an argument is rounded off, not rounded away from zero.
On Sat, 2022-12-03 at 08:54 +0000, PG Doc comments form wrote: > Explanation of the manual's ROUND function > round ( numeric ) → numeric > round ( double precision ) → double precision > Rounds to nearest integer. For numeric, ties are broken by rounding away > from zero. For double precision, the tie-breaking behavior is platform > dependent, but “round to nearest even” is the most common rule. > round(42.4) → 42 > > Operation of the ROUND function > postgres=# SELECT round(CAST(42.5 AS numeric)); > round > ------- > 43 > (1 row) > > I am thinking that the value of the ROUND function with NUMERIC as an > argument is rounded off, not rounded away from zero. It is rounded away from zero, since 43 is farther away from 0 than 42.5. This may be a language problem. Yours, Laurenz Albe
Laurenz Albe <laurenz.albe@cybertec.at> writes: > On Sat, 2022-12-03 at 08:54 +0000, PG Doc comments form wrote: >> I am thinking that the value of the ROUND function with NUMERIC as an >> argument is rounded off, not rounded away from zero. > It is rounded away from zero, since 43 is farther away from 0 than 42.5. > This may be a language problem. Perhaps, since I don't see anything wrong with that text either. (Of course, it's moderately likely that I wrote that text, or at least copy-edited it at some point ;-). Don't remember.) The point is that for 42.5, or anything-point-5, the basic "round to nearest integer" rule is insufficient because 42 and 43 are equally near. We need a tie-breaking rule, and for numeric that rule has historically been to round to the larger absolute value (or "away from zero", as the text puts it to avoid two-dollar terminology). Sadly, that is not what IEEE has established as best practice for floating-point rounding, so round(float8) acts differently. regards, tom lane
Thank you for your answer.
I am convinced.
Thank you for replying to my question in poor English.
I am convinced.
Thank you for replying to my question in poor English.
2022年12月3日(土) 23:19 Tom Lane <tgl@sss.pgh.pa.us>:
Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Sat, 2022-12-03 at 08:54 +0000, PG Doc comments form wrote:
>> I am thinking that the value of the ROUND function with NUMERIC as an
>> argument is rounded off, not rounded away from zero.
> It is rounded away from zero, since 43 is farther away from 0 than 42.5.
> This may be a language problem.
Perhaps, since I don't see anything wrong with that text either.
(Of course, it's moderately likely that I wrote that text,
or at least copy-edited it at some point ;-). Don't remember.)
The point is that for 42.5, or anything-point-5, the basic
"round to nearest integer" rule is insufficient because 42 and
43 are equally near. We need a tie-breaking rule, and for numeric
that rule has historically been to round to the larger absolute
value (or "away from zero", as the text puts it to avoid two-dollar
terminology). Sadly, that is not what IEEE has established as
best practice for floating-point rounding, so round(float8)
acts differently.
regards, tom lane