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

On Thu, 19 Nov 1998, Tom Lane wrote:

>"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).

Yep, you are right. I missed the query that multiplies every row in
FLOAT8_TBL by -1.

>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.

Me too.

>>> 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.

The differences appear only when the row(s) correspond to the year 1947,
and the only difference is between "PST" and "PDT" at the end of the date
(don't remember right now which one is the expected).

>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...

This was not the case. Yes, I did an initdb, and the order of expected and
real results was the same.

After all this, I would say that 6.4 is quite useable in Digital Unix. I
will be moving my production database in the next weeks.

-------------------------------------------------------------------
Pedro José Lobo Perea Tel: +34 91 336 78 19
Centro de Cálculo Fax: +34 91 331 92 29
EUIT Telecomunicación - UPM e-mail: pjlobo(at)euitt(dot)upm(dot)es