Thread: some errors and/or bugs?

func.sgml line 251:
cbrt(27.0) = 3.0, not 9.0,
so it seems it's not the reault of: select cbrt(27.0); but someone's
thinking. :-)

and line 283 floor()'s result, 43, miss a minus, should be -43

and for the round( numeric ):
laser_zh=# select round(42.5);
 round
-------
    42
(1 row)

is it correct? I think result should be 43.
but for round( numeric, int):

laser_zh=# select round(42.4352, 2);
 round
-------
 42.44
(1 row)

seems correct.

Bug I don't know if there something related with my OS,
I'm using Slackware 7.1 glibc 2.1.3.
I could write some simple program to test it further, but need more
hints.

Regards

Laser

"He Weiping(Laser Henry)" <laser@zhengmai.com.cn> writes:
> laser_zh=# select round(42.5);
>  round
> -------
>     42
> (1 row)
>
> is it correct? I think result should be 43.

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.

Also, the numeric round() function is just plain broken:

regression=# select round(42.5::numeric);
ERROR:  Function 'numeric_round(numeric, int4)' does not exist
        Unable to identify a function that satisfies the given argument types
        You may need to add explicit typecasts
regression=# select round(42.5::numeric,0);
 round
-------
    43
(1 row)

Looks like a silly oversight in the pg_proc entry for round(numeric).

            regards, tom lane

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.

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.

--
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

Peter Eisentraut <peter_e@gmx.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