* GSL on Hitachi SR8000
@ 2002-08-23 2:32 Reinhold Bader
2002-08-24 3:11 ` Brian Gough
0 siblings, 1 reply; 8+ messages in thread
From: Reinhold Bader @ 2002-08-23 2:32 UTC (permalink / raw)
To: gsl-discuss
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GSL on Hitachi SR8000
2002-08-23 2:32 GSL on Hitachi SR8000 Reinhold Bader
@ 2002-08-24 3:11 ` Brian Gough
2002-08-24 10:44 ` Reinhold Bader
0 siblings, 1 reply; 8+ messages in thread
From: Brian Gough @ 2002-08-24 3:11 UTC (permalink / raw)
To: Reinhold Bader; +Cc: gsl-discuss
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?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GSL on Hitachi SR8000
2002-08-24 3:11 ` Brian Gough
@ 2002-08-24 10:44 ` Reinhold Bader
2002-08-24 11:08 ` Jochen Küpper
2002-08-26 2:39 ` Brian Gough
0 siblings, 2 replies; 8+ messages in thread
From: Reinhold Bader @ 2002-08-24 10:44 UTC (permalink / raw)
To: Brian Gough; +Cc: Reinhold Bader, gsl-discuss
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?
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GSL on Hitachi SR8000
2002-08-24 10:44 ` Reinhold Bader
@ 2002-08-24 11:08 ` Jochen Küpper
2002-08-25 0:11 ` Reinhold Bader
2002-08-26 2:39 ` Brian Gough
1 sibling, 1 reply; 8+ messages in thread
From: Jochen Küpper @ 2002-08-24 11:08 UTC (permalink / raw)
To: Reinhold Bader; +Cc: Brian Gough, gsl-discuss
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GSL on Hitachi SR8000
2002-08-24 11:08 ` Jochen Küpper
@ 2002-08-25 0:11 ` Reinhold Bader
0 siblings, 0 replies; 8+ messages in thread
From: Reinhold Bader @ 2002-08-25 0:11 UTC (permalink / raw)
To: gsl-discuss
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GSL on Hitachi SR8000
2002-08-24 10:44 ` Reinhold Bader
2002-08-24 11:08 ` Jochen Küpper
@ 2002-08-26 2:39 ` Brian Gough
2002-08-26 5:27 ` Reinhold Bader
1 sibling, 1 reply; 8+ messages in thread
From: Brian Gough @ 2002-08-26 2:39 UTC (permalink / raw)
To: Reinhold Bader; +Cc: gsl-discuss
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])
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GSL on Hitachi SR8000
2002-08-26 2:39 ` Brian Gough
@ 2002-08-26 5:27 ` Reinhold Bader
2002-08-26 6:23 ` Brian Gough
0 siblings, 1 reply; 8+ messages in thread
From: Reinhold Bader @ 2002-08-26 5:27 UTC (permalink / raw)
To: Brian Gough; +Cc: Reinhold Bader, gsl-discuss
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: GSL on Hitachi SR8000
2002-08-26 5:27 ` Reinhold Bader
@ 2002-08-26 6:23 ` Brian Gough
0 siblings, 0 replies; 8+ messages in thread
From: Brian Gough @ 2002-08-26 6:23 UTC (permalink / raw)
To: Reinhold Bader; +Cc: gsl-discuss
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");
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-08-26 13:23 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-08-23 2:32 GSL on Hitachi SR8000 Reinhold Bader
2002-08-24 3:11 ` Brian Gough
2002-08-24 10:44 ` Reinhold Bader
2002-08-24 11:08 ` Jochen Küpper
2002-08-25 0:11 ` Reinhold Bader
2002-08-26 2:39 ` Brian Gough
2002-08-26 5:27 ` Reinhold Bader
2002-08-26 6:23 ` Brian Gough
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).