GSL on Hitachi SR8000

GSL on Hitachi SR8000

[Reinhold Bader]

  Hello,

   I've built the GLS 1.2 on a Hitachi SR8000 (PowerPC-derived RISC SMP 
architecture
   with prefetch extensions, OS is Mach based) and the following part of 
the test suite
   fails:

gmake[2]: Entering directory `/usr/local/src/gnulrz/gsl/gsl-1.2/ieee-utils'
PASS: float x = 0, sign is + (0 observed vs 0 expected)
PASS: float x = 0, exponent is -127 (-127 observed vs -127 expected)
PASS: float x = 0, mantissa
...
PASS: float x = FLT_MIN, sign is + (0 observed vs 0 expected)
FAIL: float x = FLT_MIN, exponent is -126 (-127 observed vs -126 expected)
PASS: float x = FLT_MIN, mantissa
FAIL: float x = FLT_MIN, type is NORMAL (5 observed vs 3 expected)
PASS: float x = FLT_MAX, sign is + (0 observed vs 0 expected)
FAIL: float x = FLT_MAX, exponent is 127 (128 observed vs 127 expected)
FAIL: float x = FLT_MAX, mantissa (00000000000000000000000 observed vs 
111111111
11111111111111 expected)
FAIL: float x = FLT_MAX, type is NORMAL (2 observed vs 3 expected)
PASS: float x = FLT_MIN/2^1, sign is + (0 observed vs 0 expected)
PASS: float x = FLT_MIN/2^1, exponent is -127 (-127 observed vs -127 
expected)
FAIL: float x = FLT_MIN/2^1, mantissa (00000000000000000000000 observed 
vs 10000
000000000000000000 expected)
(more failures follow).

Furthermore there is a failure in Legendre:

FAIL: gsl_sf_legendre_H3d_1_e(1000.0, 0.001, &r)
  expected:    0.301168758650904
  obtained:   0.3011687586509037   9.480616873741396e-16  3.14794e-15
  fracdiff: 4.60797722512139e-16
  value not within tolerance of expected value
      0.3011687586509037  9.4806168737413957e-16

and, finally

FAIL: gsl_histogram_fprintf and fscanf work correctly


Concerning the IEEE problems I've done some preliminary investigation, and
it turned out that there were warnings compiling
ieee-utils/test.c:

cc -DHAVE_CONFIG_H -I. -I. -I.. -I..    -g -c test.c
test.c: 140: Error: 3060, Constant value exceeds allowable range.
test.c: 154: Error: 3060, Constant value exceeds allowable range.
test.c: 171: Error: 3060, Constant value exceeds allowable range.
test.c: 198: Error: 3060, Constant value exceeds allowable range.
test.c: 216: Error: 3060, Constant value exceeds allowable range.
test.c: 37: Warning: 2600, Function "main" does not return a value.

replacing the constants

1.17549435e-38f  --> 1.17549436e-38f

and

3.40282347e+38f  --> 3.40282346e+38f

made these warnings vanish, and the binary now ran without failures.


Questions:

1.  Do I need to change these constants elsewhere in the library source
     to guarantee correct functionality? Does the above change indicate
     that the number format on the SR8000 is non IEEE conformant?


2.  The legendre failure seems minor. Any comments?

3.  The gsl_histogram stuff: not very urgent, but is there any hint
      where things might have gone wrong in
      gsl_histogram_fprintf and/or fscanf?


Best regards


-- 
 Dr. Reinhold Bader

 Leibniz-Rechenzentrum, Abt. Benutzerbetreuung	| Tel. +4989 289 28825
 Barerstr. 21, 80333 Muenchen			| email Bader@lrz.de

Re: GSL on Hitachi SR8000

[Brian Gough]

Reinhold Bader writes:
 > Questions:

Hi, 

Thanks for the bug report. It would be good to get GSL working on this
platform.

 > 
 > 1.  Do I need to change these constants elsewhere in the library source
 >      to guarantee correct functionality? Does the above change indicate
 >      that the number format on the SR8000 is non IEEE conformant?

Can you compare the values of FLT_MAX, FLT_MIN etc on your system with
the ones used in test.c.  Try compiling with FLT_MAX, FLT_MIN in the
source code instead of the hardcoded values.

 > 2.  The legendre failure seems minor. Any comments?

Yes, looks like a variation in rounding only.

 > 3.  The gsl_histogram stuff: not very urgent, but is there any hint
 >       where things might have gone wrong in
 >       gsl_histogram_fprintf and/or fscanf?

This error is perhaps more serious, I have never seen it fail before
-- can you step through the appropriate part of the test program under
the debugger?

Thanks,
Brian Gough

p.s. what compiler do you use?

Re: GSL on Hitachi SR8000

[Reinhold Bader]

Right,

/usr/include/machine/float_limits defines, among other things

#define FLT_DIG         6
#define FLT_MIN         1.1754943508222875e-38F
#define FLT_MAX         3.4028234663852886e+38F

With these values the test program compiles without warnings and
runs correctly.


Concerning histogram, I've inserted some printf's after the fscanf
call:

     for (i = 0; i < N; i++)
       {
         if (h->range[i] != hh->range[i]) {
           printf("failure of range for i=%d: %20.16f %20.16f\n",i,h->range[i],abs(h->range[i] - hh->range[i]));
           status = 1;
         }
         if (h->bin[i] != hh->bin[i]) {
           printf("failure of bin for i=%d\n",i);
           status = 1;
         }
       }

and receive failures for h->range. Oddly enough, the absolute differences are
0:
failure of range for i=1:   0.0025188916876574   0.0000000000000000
failure of range for i=2:   0.0050377833753149   0.0000000000000000
failure of range for i=3:   0.0075566750629723   0.0000000000000000
failure of range for i=4:   0.0100755667506297   0.0000000000000000
failure of range for i=5:   0.0125944584382872   0.0000000000000000

perhaps the machine differentiates 0.0 and -0.0? Generally, comparing
floats etc. to equality is generally not a good idea (and you do
read in %lg's in gsl_histogram_fscanf)...


Best regards



Brian Gough wrote:
> Reinhold Bader writes:
>  > Questions:
> 
> Hi, 
> 
> Thanks for the bug report. It would be good to get GSL working on this
> platform.
> 
>  > 
>  > 1.  Do I need to change these constants elsewhere in the library source
>  >      to guarantee correct functionality? Does the above change indicate
>  >      that the number format on the SR8000 is non IEEE conformant?
> 
> Can you compare the values of FLT_MAX, FLT_MIN etc on your system with
> the ones used in test.c.  Try compiling with FLT_MAX, FLT_MIN in the
> source code instead of the hardcoded values.
> 
>  > 2.  The legendre failure seems minor. Any comments?
> 
> Yes, looks like a variation in rounding only.
> 
>  > 3.  The gsl_histogram stuff: not very urgent, but is there any hint
>  >       where things might have gone wrong in
>  >       gsl_histogram_fprintf and/or fscanf?
> 
> This error is perhaps more serious, I have never seen it fail before
> -- can you step through the appropriate part of the test program under
> the debugger?
> 
> Thanks,
> Brian Gough
> 
> p.s. what compiler do you use?
> 

Re: GSL on Hitachi SR8000

[Jochen Küpper]

On Sat, 24 Aug 2002 19:45:04 +0200 Reinhold Bader wrote:

Reinhold> printf("failure of range for i=%d: %20.16f %20.16f\n",i,h->range[i],abs(h->range[i] - hh->range[i]));

Reinhold> and receive failures for h->range. Oddly enough, the absolute differences are
Reinhold> 0:
Reinhold> failure of range for i=1:   0.0025188916876574   0.0000000000000000
Reinhold> failure of range for i=2:   0.0050377833753149   0.0000000000000000
Reinhold> failure of range for i=3:   0.0075566750629723   0.0000000000000000
Reinhold> failure of range for i=4:   0.0100755667506297   0.0000000000000000
Reinhold> failure of range for i=5:   0.0125944584382872   0.0000000000000000

Reinhold> perhaps the machine differentiates 0.0 and -0.0? Generally, comparing
Reinhold> floats etc. to equality is generally not a good idea (and you do
Reinhold> read in %lg's in gsl_histogram_fscanf)...

Hmm, what's the output if you use %g instead of %f?

Greetings,
Jochen
-- 
University of North Carolina                       phone: +1-919-962-4403
Department of Chemistry                            phone: +1-919-962-1579
Venable Hall CB#3290 (Kenan C148)                    fax: +1-919-843-6041
Chapel Hill, NC 27599, USA                            GnuPG key: 44BCCD8E

Re: GSL on Hitachi SR8000

[Reinhold Bader]

Here it is (sorry for that slip):



failure of range for i=1: 0.002518891687657430 2.653385558828668e-315
failure of range for i=2: 0.005037783375314860 2.653385558828668e-315
failure of range for i=3: 0.007556675062972290 2.653385558828668e-315
failure of range for i=4:  0.01007556675062972 2.653385558828668e-315
failure of range for i=5:  0.01259445843828715 2.653385558828668e-315
failure of range for i=6:  0.01511335012594458 2.653385558828668e-315
failure of range for i=7:  0.01763224181360202 2.653385558828668e-315
failure of range for i=8:  0.02015113350125945 2.653385558828668e-315
failure of range for i=9:  0.02267002518891688 2.653385558828668e-315
... etc up to i=34

etc.

Jochen Küpper wrote:
 > On Sat, 24 Aug 2002 19:45:04 +0200 Reinhold Bader wrote:
 >
 > Reinhold> printf("failure of range for i=%d: %20.16f %20.16f\n",i,h->range[i],abs(h->range[i] - hh->range[i]));
 >
 > Reinhold> and receive failures for h->range. Oddly enough, the absolute differences are
 > Reinhold> 0:
 > Reinhold> failure of range for i=1:   0.0025188916876574   0.0000000000000000
 > Reinhold> failure of range for i=2:   0.0050377833753149   0.0000000000000000
 > Reinhold> failure of range for i=3:   0.0075566750629723   0.0000000000000000
 > Reinhold> failure of range for i=4:   0.0100755667506297   0.0000000000000000
 > Reinhold> failure of range for i=5:   0.0125944584382872   0.0000000000000000
 >
 > Reinhold> perhaps the machine differentiates 0.0 and -0.0? Generally, comparing
 > Reinhold> floats etc. to equality is generally not a good idea (and you do
 > Reinhold> read in %lg's in gsl_histogram_fscanf)...
 >
 > Hmm, what's the output if you use %g instead of %f?
 >
 > Greetings,
 > Jochen

Re: GSL on Hitachi SR8000

[Brian Gough]

Reinhold Bader writes:
 >            printf("failure of range for i=%d: %20.16f %20.16f\n",i,h->range[i],abs(h->range[i] - hh->range[i]));

abs() returns an integer value, hence the strange floating point value 
O(1e-318).

Try this instead:

printf("failure i=%d: %.19e %.19e %.19e\n",i,h->range[i], hh->range[i], hh->range[i] - h->range[i])

Re: GSL on Hitachi SR8000

[Reinhold Bader]

Brian Gough wrote:

>Reinhold Bader writes:
> >            printf("failure of range for i=%d: %20.16f %20.16f\n",i,h->range[i],abs(h->range[i] - hh->range[i]));
>
>abs() returns an integer value, hence the strange floating point value 
>O(1e-318).
>
>Try this instead:
>
>printf("failure i=%d: %.19e %.19e %.19e\n",i,h->range[i], hh->range[i], hh->range[i] - h->range[i])
>  
>
failure i=1: 2.5188916876574307000e-03 2.5188916876574298000e-03 
-8.6736173798840355000e-19
failure i=2: 5.0377833753148613000e-03 5.0377833753148596000e-03 
-1.7347234759768071000e-18
failure i=3: 7.5566750629722920000e-03 7.5566750629722903000e-03 
-1.7347234759768071000e-18
failure i=4: 1.0075566750629723000e-02 1.0075566750629719000e-02 
-3.4694469519536142000e-18
failure i=5: 1.2594458438287154000e-02 1.2594458438287151000e-02 
-3.4694469519536142000e-18
failure i=6: 1.5113350125944584000e-02 1.5113350125944581000e-02 
-3.4694469519536142000e-18
etc. (up to i=34)



-- 
 Dr. Reinhold Bader

 Leibniz-Rechenzentrum, Abt. Benutzerbetreuung	| Tel. +4989 289 28825
 Barerstr. 21, 80333 Muenchen			| email Bader@lrz.de

Re: GSL on Hitachi SR8000

[Brian Gough]

Maybe there's a discrepancy with the output from the %g format.  Try
this patch on the test programs to use %e instead:

Index: test.c
===================================================================
RCS file: /cvs/gsl/gsl/histogram/test.c,v
retrieving revision 1.22
diff -r1.22 test.c
422c422
<     gsl_histogram_fprintf (f, h, "%.19g", "%.19g");
---
>     gsl_histogram_fprintf (f, h, "%.19e", "%.19e");
Index: test2d.c
===================================================================
RCS file: /cvs/gsl/gsl/histogram/test2d.c,v
retrieving revision 1.23
diff -r1.23 test2d.c
653c653
<     gsl_histogram2d_fprintf (f, h, "%.19g", "%.19g");
---
>     gsl_histogram2d_fprintf (f, h, "%.19e", "%.19e");