Thread

1. Re: [HACKERS] Regression tests on intel for 6.5.2

   Tom Lane <tgl@sss.pgh.pa.us> — 1999-09-27T23:46:53Z

   Lamar Owen <lamar.owen@wgcr.org> writes:
   > In the course of building and testing the rpm's for 6.5.2, unexpected
   > results were found in the regression testing.  I am curious as to what
   > the results for 'float8' mean (geometry also failed, but it's obvious as
   > to why):
   
   I saw similar results with older Postgres releases on HPUX.  The problem
   is failure to detect an invalid result from the exp() library function.
   Unfortunately there's not complete uniformity about how to test that
   on different platforms.
   
   What's currently in dexp() in backend/utils/adt/float.c is
   
   #ifndef finite
   	errno = 0;
   #endif
   	*result = (float64data) exp(tmp);
   #ifndef finite
   	if (errno == ERANGE)
   #else
   	/* infinity implies overflow, zero implies underflow */
   	if (!finite(*result) || *result == 0.0)
   #endif
   		elog(ERROR, "exp() result is out of range");
   
   which is evidently doing the wrong thing on your platform.  What does
   your man page for exp() say about error return conventions?
   
   I suspect the assumption that finite() is always implemented as a macro
   if it's present at all is the weak spot ... or it might be that your
   math lib returns some other error code like EDOM ...
   
   			regards, tom lane
   
   

2. Re: [HACKERS] Regression tests on intel for 6.5.2

   Lamar Owen <lamar.owen@wgcr.org> — 1999-09-27T23:52:07Z

   On Mon, 27 Sep 1999, Tom Lane wrote:
   > which is evidently doing the wrong thing on your platform.  What does
   > your man page for exp() say about error return conventions?
   
   Platform is Intel Linux -- specifically:
   RedHat Linux 6.0/Intel (glibc 2.1.1):
   
   Man page for exp(3)...
   -------------------
   The log() and log10() functions can return the following errors: 
   
   EDOM  
   The argument x is negative.  
   
   ERANGE The argument x is zero. The log of zero is not defined. 
   
   The pow() function can return the following error: 
   
   EDOM  
   The argument x is negative and y is not an integral value. This would result in a complex number.  
   -------------------------------
   
   > I suspect the assumption that finite() is always implemented as a macro
   > if it's present at all is the weak spot ... or it might be that your
   > math lib returns some other error code like EDOM ...
   
   Man page finite(3)
   -------------------------------
   The finite() function returns a non-zero value if value is neither infinite nor a 
   not-a-number (NaN) value, and 0 otherwise. 
   -------------------------------
   
   Seems that there was a table in those regression test results populated by
   NaN....
   
   -----------------------------------------------------------------------------
   Lamar Owen
   WGCR Internet Radio
   1 Peter 4:11
   
   

3. Re: [HACKERS] Regression tests on intel for 6.5.2

   Christof Petig <christof.petig@wtal.de> — 1999-09-29T15:05:34Z

   Lamar Owen wrote:
   
   > On Mon, 27 Sep 1999, Tom Lane wrote:
   > > which is evidently doing the wrong thing on your platform.  What does
   > > your man page for exp() say about error return conventions?
   >
   
   I checked it twice, I can't find any error in the current sources. I even wrote a test program:
   #include <math.h>
   #include <stdio.h>
   #include <errno.h>
   
   int main()
   {  double e;
      errno=0;
      e=pow(100,200);
      if (errno) perror("pow");
      if (!finite(e)) puts("!finite\n");
      else printf("%f\n",e);
   }
   
   Output:
   pow: Numerical result out of range
   !finite
   
   So both methods seem to work. (finite is a function on glibc-2.1 systems)
   
   Perhaps (strange thoughts come in to my mind ...) the compiler optimizes the function call into a
   machine instruction ...
   /tmp> cc -O2 -o test test.c -lm
   /tmp> ./test
   !finite
   
   Looks like this is the case. So (I use gcc-2.95) what to do? Complain about a compiler/library bug
   (doesn't set errno)? I would propose another autoconf test. (I could easily do it.)
   
    Christof
   
   PS: I found the offending inline routines in /usr/include/bits/mathinline.h
   
   
   
   

4. Re: [HACKERS] Regression tests on intel for 6.5.2

   Thomas Lockhart <lockhart@alumni.caltech.edu> — 1999-09-30T06:17:00Z

   > > > which is evidently doing the wrong thing on your platform.  What does
   > > > your man page for exp() say about error return conventions?
   > I checked it twice, I can't find any error in the current sources. I even wrote a test 
   > program...
   > So both methods seem to work. (finite is a function on glibc-2.1 systems)
   
   And that is the problem. I didn't have enough platforms to test on, so
   when I improved the code I did so in a way that I would get a better
   result on at least my platform (probably RH4.2 or earlier) without
   breaking the behavior on other platforms.
   
   So, I test locally for finite() being defined as a macro! But on newer
   glibc systems it is a real function, so you are seeing the old
   behavior.
   
   A better thing to do would be to define HAVE_FINITE, and to have a
   ./configure test for it. That should be easy enough; do you have time
   to look at it? Then code like
   
   #ifndef finite
       if (errno == ERANGE)
   #else
       /* infinity implies overflow, zero implies underflow */
       if (!finite(*result) || *result == 0.0)
   #endif
   
   Could become
   
   ...
   #if HAVE_FINITE
   ...
   
                           - Thomas
   
   -- 
   Thomas Lockhart				lockhart@alumni.caltech.edu
   South Pasadena, California