Re: ROUND function ??

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.

In response to

Browse pgsql-sql by date

  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