Re: [HACKERS] More on 6.4 on DEC Alpha + Digital Unix 4.0d + DEC C compiler
Thomas Lockhart <lockhart@alumni.caltech.edu>
From: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Pedro J. Lobo" <pjlobo@euitt.upm.es>, PostgreSQL hackers mailing list <pgsql-hackers@postgreSQL.org>
Date: 1998-11-24T02:35:41Z
Lists: pgsql-hackers
> > 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