Обсуждение: Explanation of the ROUND function with NUMERIC as an argument

Поиск
Список
Период
Сортировка

Explanation of the ROUND function with NUMERIC as an argument

От
PG Doc comments form
Дата:
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.

Re: Explanation of the ROUND function with NUMERIC as an argument

От
Laurenz Albe
Дата:
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



Re: Explanation of the ROUND function with NUMERIC as an argument

От
Tom Lane
Дата:
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



Re: Explanation of the ROUND function with NUMERIC as an argument

От
hirokazu kamiya
Дата:
Thank you for your answer.
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