This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: make check error


Dear Brian,

The patch doesn't fix the make check error with RedHat 7.0 /
gcc2.96, but the problem is definitely in the comparison of 0.0
to 'GSL_EUNDRFLW' in gsl_sf_multiply_impl() when multiplying
DBL_MIN * DBL_MIN.  Stepping through gsl_sf_multiply_impl() with
gdb didn't reveal anything glaring to me except that 
  ax = fabs(x)  = 0.  
when  
  x  = GSL_DBL_MIN .

which makes me wonder whether the very first test in
gsl_sf_multiply_impl() might be 
 if (ax == 0.0 | ay == 0.0) { }

instead of
 if ( x == 0.0 |  y == 0.0) { }

But, assuming that was correct as coded, this change to 
specfun/elementary.c allows 'make check' to pass all tests:

61,62c61
<       /* return (result->val == 0.0 ? GSL_EUNDRFLW : GSL_SUCCESS);*/
<       return ((fabs(result->val) < GSL_DBL_MIN) ? GSL_EUNDRFLW : GSL_SUCCESS);
---
>       return (result->val == 0.0 ? GSL_EUNDRFLW : GSL_SUCCESS);

I'm not sure if comparing to GSL_DBL_MIN is the best choice, but
deciding non-success based on "x == 0.0"  seems dangerous, no?  
The comments in gsl_sf_multiply_impl()  hint that this problem
is a known issue, and that the use of a "volatile double tmp"
should be be double-checked.

I may be missing the point of checking whether DBL_MIN*DBL_MIN
is Underflow or 0.  It all seems a little pedantic to me. 

The bad news is that passing the tests in specfun reveals other
failures with RH7.0 and gcc2.96 in integration/ and monte/

integration:
make  check-TESTS
PASS: qag(f3,31pt) oscill result (-0.723897 observed vs -0.723897 expected)
FAIL: qag(f3,31pt) oscill abserr (1.28571716286847917e-14 observed vs 1.28580546442745926e-14 expected)
FAIL: qag(f3,31pt) oscill neval (403 observed vs 31 expected)
FAIL: qag(f3,31pt) oscill last (7 observed vs 1 expected)
PASS: qag(f3,31pt) oscill status (18 observed vs 18 expected)
PASS: qag(f3,31pt) reverse result (0.723897 observed vs 0.723897 expected)
FAIL: qag(f3,31pt) reverse abserr (1.28571716286847917e-14 observed vs 1.28580546442745926e-14 expected)
FAIL: qag(f3,31pt) reverse neval (403 observed vs 31 expected)
FAIL: qag(f3,31pt) reverse last (7 observed vs 1 expected)
PASS: qag(f3,31pt) reverse status (18 observed vs 18 expected)

monte:
make  check-TESTS

Testing single gaussian
FAIL: vegas(f1), dim=9, err=0.0026, chisq=138.4868 (0.989678118577861921 observed vs 1 expected)

Testing double gaussian
FAIL: miser(f2), dim=9, err=0.0530 (0.888171870752243353 observed vs 1 expected)

I haven't looked into these any further yet.

Thanks for everything, 

--Matt Newville

 |= Matthew Newville      email: newville@cars.uchicago.edu           =|
 |= GSECARS, Bldg 434A    voice: (630) 252-0431                       =|
 |= Argonne Natl Lab      fax:   (630) 252-0443                       =|
 |= 9700 South Cass Ave   www:   http://cars9.uchicago.edu/~newville/ =|
 |= Argonne, IL 60439 USA                                             =|



On Sat, 4 Nov 2000, Brian Gough wrote:

> Thanks for the bug report. 
> 
> It looks like there is a new problem with overflow/underflow on RH7,
> as this is the second report of this failure.  Unfortunately the test
> program does not print anything for the cases which are probably
> causing it.
> 
>  If someone could try out the patch below it should indicate the line
> that is causing the problem (if you can step through that function
> with the debugger and see what is going on that will be very useful).
> 
> Brian
> 
> 
> Index: specfunc/test_sf.c
> ===================================================================
> RCS file: /cvs/gsl/gsl/specfunc/test_sf.c,v
> retrieving revision 1.162
> diff -r1.162 test_sf.c
> 288,290c288,305
> <   s += ( gsl_sf_multiply_impl(DBL_MAX, 1.1, &r) != GSL_EOVRFLW);
> <   s += ( gsl_sf_multiply_impl(DBL_MIN,  DBL_MIN, &r) != GSL_EUNDRFLW);
> <   s += ( gsl_sf_multiply_impl(DBL_MIN, -DBL_MIN, &r) != GSL_EUNDRFLW);
> ---
> >   
> >   {
> >     int status = gsl_sf_multiply_impl(DBL_MAX, 1.1, &r);
> >     gsl_test_int (status, GSL_EOVRFLW, "  gsl_sf_multiply_impl(DBL_MAX,1.1)");
> >     s += (status != GSL_EOVRFLW);
> >   }
> > 
> >   {
> >     int status = gsl_sf_multiply_impl(DBL_MIN, DBL_MIN, &r);
> >     gsl_test_int (status, GSL_EUNDRFLW, "  gsl_sf_multiply_impl(DBL_MIN,DBL_MIN)");
> >     s += (status != GSL_EUNDRFLW);
> >   }
> > 
> >   {
> >     int status = gsl_sf_multiply_impl(DBL_MIN, -DBL_MIN, &r);
> >     gsl_test_int (status, GSL_EUNDRFLW, "  gsl_sf_multiply_impl(DBL_MIN,-DBL_MIN)");
> >     s += (status != GSL_EUNDRFLW);
> >   }
> 












Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]