Re: rounding_up - Mailing list pgsql-hackers

From Daria Shanina
Subject Re: rounding_up
Date
Msg-id CAMp4U1cvxALSe+RVmNkK-Ne3MHED6G0Dc9Zj_u5FRms0AB06bA@mail.gmail.com
Whole thread Raw
In response to Re: rounding_up  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

Hi, Tom!

> Round-to-nearest-even is a well-respected rule

Yes, you're convinced me! I can’t argue with IEEE 754 =) And, of course, can’t break compatibility.


Best regards,

Daria Shanina


пн, 14 апр. 2025 г. в 17:26, Tom Lane <tgl@sss.pgh.pa.us>:
Christoph Moench-Tegeder <cmt@burggraben.net> writes:
> ## Daria Shanina (vilensipkdm@gmail.com):
>> I noticed, when we parse and validate values (in particular, the int type),
>> we use the *rint* method, but unfortunately it does not work according to
>> the round rules.

> First question would be "which round rule?" as (of course) there're
> multiple to chose from.

Yeah.  Round-to-nearest-even is a well-respected rule, which is why
it's the default per IEEE 754.  I don't see a good reason for us
to switch.  Even if someone advanced an argument, it would have
to be a *mighty* convincing argument to justify breaking backwards
compatibility here.

I do find it a little unfortunate that our numeric type does it
differently than our float types.  Again though, there's a huge
compatibility argument against changing that now.  It does give
you an "out" if you really need one or the other behavior for
a particular application: you can cast to numeric or float8
before casting to int.

                        regards, tom lane


--
С уважением,
Шанина Дарья Александровна

pgsql-hackers by date:

Previous
From: Abhishek Chanda
Date:
Subject: Re: Adding error messages to a few slash commands
Next
From: Pavel Stehule
Date:
Subject: Re: Performance issues with v18 SQL-language-function changes