Re: [HACKERS] More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler

"Thomas G. Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu> writes:
> "Pedro J. Lobo" <pjlobo(at)euitt(dot)upm(dot)es> wrote:
>> 1) THE REGRESSION TEST FOR FLOAT8 IS BROKEN!!!
>> the "expected" output for the exp() operator ":" is brain damaged.

> The reference platform never lies.

In this case the reference platform is broken, IMHO.

However, Pedro's not batting 1.000 today either. The exp() problem
is not overflow but underflow, because a prior query in the float8
test alters the table. At the point where the test in question
executes, the actual contents of the f1 table are

QUERY: SELECT '' AS five, FLOAT8_TBL.*;
five|f1
----+---------------------
|0
|-34.84
|-1004.3
|-1.2345678901234e+200
|-1.2345678901234e-200
(5 rows)

(taken verbatim from a few lines further down in the "expected" output).

The "expected" output is

QUERY: SELECT '' AS bad, : (f.f1) from FLOAT8_TBL f;
bad| ?column?
---+--------------------
| 1
|7.39912306090513e-16
| 0
| 0
| 1
(5 rows)

The first two of these are right, and so is the last one, but the
third and fourth lines represent underflow. On my machine, when
the result of exp(x) is too small to store as a double, the returned
result is 0 and errno is set to ERANGE --- and this is the behavior
demanded by ANSI C, according to my reference materials.

The implementation of exp() in float.c reads

#ifndef finite
errno = 0;
#endif
*result = (float64data) exp(tmp);
#ifndef finite
if (errno == ERANGE)
#else
if (!finite(*result))
#endif
elog(ERROR, "exp() result is out of range");

Pedro's machine and my machine are obeying the ANSI specification
and producing the "exp() result is out of range" error.

Thomas' machine is evidently following the "ifdef finite" path.
Zero, however, is finite, so his machine is failing to notice the
underflow.

I think we have two possible courses of action here:

1. Follow the ANSI spec and raise an error for exp() underflow.
The ERRNO path is already OK for this, but the other would have
to be made to read
if (!finite(*result) || *result == 0.0)
and we'd have to fix the expected regress output.

2. Decide that we are smarter than the ANSI C authors and the
inventors of libm, and that a small exp() result should quietly
underflow to zero. In that case the ERRNO path would have to read
if (errno == ERANGE && *result != 0.0)

I like choice #1 myself.

BTW, while I was at it I took the time to figure out why the
pow() part of the test was failing for me (I was getting zeroes
instead of the expected "pow() result is out of range" error).
Turns out that depending on which HPUX math library version you
use, pow() might fail with EDOM rather than ERANGE for negative
inputs. I'll change the pow() code to check for either errno
when I get a chance.

>> 7) The abstime, tinterval and horology tests fail. It seems to be
>> caused by incorrect handling of the daylight savings. However, the
>> output seems to be "less incorrect" than on previous versions.

On some Unix boxes, the standard time library doesn't know about
daylight savings time for dates before 1970. This causes localized
discrepancies in the horology results. I don't see any failures
related to this in abstime or tinterval, however.

tinterval used to have problems with outputs appearing in a bogus
sort order, but that was fixed by some pg_operator patches applied
only a week or so before 6.4 release. Did you do an initdb after
installing 6.4? If not then you still have the busted operator
table entries...

regards, tom lane