[Discuss] Test for positive gives wacko results for underflowed values for the gcc compiler suite (including the gcc compiler, and g77 and gfortran compilers)

[Alan W. Irwin]

On 2007-06-25 14:24-0700 pw wrote:

> Alan W. Irwin wrote:
>> 
>> Anybody have a clue about what is going on here between the bad results 
>> for
>> fortran and C on the one hand and good results for python on the other?
>> 
>> Is this a gcc (and g77 and gfortran) issue?  I would appreciate it if
>> somebody would run the above C test codes with different C
>> compilers/platforms.
>>
>
> Setting the precision back to IEEE 754 single precision gives a
> different answer.
>
>
>      DOUBLE PRECISION x, xscale
>      x = 1.d-126
>      xscale = 1.d+127
>      write(*,'(1p3d15.5)') x, xscale, x/xscale
>      write(*,*) x/xscale.gt.0.d0
>      write(*,*) x/xscale.gt.1.d-305
>      write(*,*) log(x/xscale)
>      end
>
>
> test.exe
>
>    1.00000-126    1.00000+127    1.00000-253
> T
> T
>  -582.554028527494
>

The above test gives x/xscale = 1.d-254 which will not underflow for double
precision (which is what you have specified).  If you try SINGLE PRECISION
(or real*4) and use constants of 1.d-30 and 1.d30
it underflows (since the IEEE 754 normalized underflow limit for single precision
is about 10^ -37.9), and you end up with the same bad behaviour
(note your second x/xscale test has to read

write(*,*) x/xscale.gt.1.d-37).

The single-precision result is

     1.00000E-30    1.00000E+30    0.00000E+00
  T
  F
  -138.155106

That's a second surprise for me.  log is implicitly single precision if its
argument is (as in this case), yet it gives a good result (under g77) even
if its single-precision argument is zero!  Probably g77 does a lot in double
precision behind the scenes, and this behaviour is just an artifact of that.

Anyhow, for the most reliable and consistent testing, I suggest we should
stick to double precision as in my original test code.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________