Skip site navigation (1) Skip section navigation (2)

Re: some errors and/or bugs?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: "He Weiping(Laser Henry)" <laser(at)zhengmai(dot)com(dot)cn>, pgsql-docs(at)postgresql(dot)org
Subject: Re: some errors and/or bugs?
Date: 2000-12-20 19:35:44
Message-ID: 10051.977340944@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-docs
Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Tom Lane writes:
>> It's correct, if the underlying float arithmetic is IEEE-compliant.
>> Rounding for exact half-integral values is supposed to be "round to
>> nearest even".  So 42.5 goes to 42, but 43.5 goes to 44.
>> 
>> I notice our NUMERIC rounding code does not do that ... perhaps it
>> should.

> More precisely, an IEEE-compliant system would offer the choice of
> rounding up, rounding down, rounding toward zero, or rounding toward even.
> I would guess that the default is merely the potentially best performing.

Hmm.  Round-toward-even is preferred by numerical analysts on the theory
that it introduces less systematic bias than simpler rounding rules.
(If you always round half-integral values in the same direction, then
your results are slightly biased, just as if you'd set the up/down split
point at say 0.4 instead of 0.5.)  However this theory only holds if you
assume an imprecise starting value.  That's a reasonable assumption for
float arithmetic, but not so reasonable for type numeric.

> We could offer these options (much more easily) for the numeric case, but
> since numeric is very often used for business type applications, the
> customary rounding method (up) should be preferred.

You're probably right, we shouldn't change it.

			regards, tom lane

In response to

pgsql-docs by date

Next:From: Tom LaneDate: 2000-12-20 20:00:21
Subject: Re: Who is a maintainer of GiST code ?
Previous:From: Thomas LockhartDate: 2000-12-20 18:18:01
Subject: Re: Re: Generating HISTORY file

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group