From: | Allan Engelhardt <allane(at)cybaea(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, lattim(at)hotmail(dot)com |
Subject: | Re: ROUND function ?? |
Date: | 2001-10-09 23:16:42 |
Message-ID: | 3BC3855A.9909FE71@cybaea.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Tom Lane wrote:
> [...]Because the IEEE float math standard says so. Round-to-nearest-even
> is considered good practice.
I learn something new every day. :-)
While it is true that IEEE 754 defaults to "round-to-nearest", which means rounding midway points to even, it is slightly confusing that this is implemented in the math library (libc) by the rint function (subject to compiler defaults and fesetround calls) while the round functions ((ll|l)?round(f|l)?) of the library does indeed 'round half-way cases away from zero to the nearest integer', which is also the mathematical behavior. Try
% info libc Arithmetic Rounding
% info libc Arithmetic 'Arithmetic Functions' 'Rounding Functions'
on you local friendly U*ix clone and you shall find enlightenment...
The SQL standard seems to leave it implementation dependent ('92, sec 4.4.1):
An approximation obtained by rounding of a numerical value N for
an <exact numeric type> T is a value V representable in T such
that the absolute value of the difference between N and the nu-
merical value of V is not greater than half the absolute value
of the difference between two successive numerical values repre-
sentable in T. If there are more than one such values V, then it is
implementation-defined which one is taken.
So PostgreSQL does "the right thing" (again!).
Allan.
From | Date | Subject | |
---|---|---|---|
Next Message | Stuart Grimshaw | 2001-10-10 12:35:27 | Why would this slow the query down so much? |
Previous Message | Josh Berkus | 2001-10-09 21:35:46 | Re: Loading current_user and current_timestamp using COPY |