Thread
-
Re: [HACKERS] More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler
Tom Lane <tgl@sss.pgh.pa.us> — 1998-11-19T16:09:10Z
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes: > "Pedro J. Lobo" <pjlobo@euitt.upm.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 -
Re: [HACKERS] More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler
Pedro J. Lobo <pjlobo@euitt.upm.es> — 1998-11-19T18:49:11Z
On Thu, 19 Nov 1998, Tom Lane wrote: >"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes: >> "Pedro J. Lobo" <pjlobo@euitt.upm.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@euitt.upm.es
-
Re: [HACKERS] More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler
Thomas Lockhart <lockhart@alumni.caltech.edu> — 1998-11-24T02:35:41Z
> > The reference platform never lies. > In this case the reference platform is broken, IMHO. Uh, yes. I was hoping that my statement was outrageous enough to be prima facia absurd. Ha Ha. Pretty funny, eh? > 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. OK, sounds good. > 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. Hmm. Any chance of making that HP-specific? It would be a shame to make every platform test for two values on every calculation... Regards. - Tom