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: gsl 0.8 compile error


Brian Gough <bjg@network-theory.co.uk> writes:

> Toby White writes:
>  > The patches below fix it - however, make check throws up a couple
>  > of errors - I've addressed these in a separate post. This has 
>  > only been tested on OpenBSD 2.9, but should work for any version
>  > after 2.0.
>  > 
> 
> Thanks. I have added that.  
> 
> Regarding the errors in complex I am suspicious of a few of them. In
> particular,
> 
> FAIL: gsl_complex_arcsin imag part at (0.5,1.19209e-07) (1.37651030870007706e-07 observed vs 1.37651030824094312e-07 expected)
> 
> has a relative error of 3.33549e-10 but should be accurate to nearly
> full precision (according to the paper of Hull et al).  If I run the
> tests with GSL_IEEE_MODE=double-precision on x86 they pass ok, so they
> should work on any machine with correct IEEE arithmetic.  Perhaps
> there is an error in hypot() or log1p() on Openbsd??? (Does it use the
> system functions or the ones in GSL?)

Hmm. It uses the system functions by default. If I make it use gsl_log1p, then the only errors I get are:

FAIL: gsl_complex_arctanh real part at (1.19209e-07,0) (1.19209289550780125e-07 observed vs 1.19209289550781806e-07 expected)
FAIL: gsl_complex_arctanh real part at (-1.19209e-07,0) (-1.19209289550780125e-07 observed vs -1.19209289550781806e-07 expected)
FAIL: gsl_complex_arccoth real part at (1.19209e-07,0) (1.19209289550780125e-07 observed vs 1.19209289550781806e-07 expected)
FAIL: gsl_complex_arccoth real part at (-1.19209e-07,0) (-1.19209289550780125e-07 observed vs -1.19209289550781806e-07 expected)

and these remain even if I force it to use gsl_hypot and gsl_atanh.

The OpenBSD math functions are also lifted straight from NetBSD -
the source can be seen on the OpenBSD website (CVSweb - under
src/lib/libm/src) and by the look of the NetBSD source, is still
more or less identical. So NetBSD ought to suffer the same faults.
(The FreeBSD source seems to be substantially different; though
it claims to use the same method - a "Reme algorithm", apparently)

You are quite sure that the OpenBSD answer is the wrong one? I'm
happy to believe it, but it probably warrants some investigation, 
and a bug report to OpenBSD, if so.

Toby

-- 
Toby White, University Chemical Lab., Lensfield Road, Cambridge. CB2 1EW. U.K.
Email: <tow@theor.ch.cam.ac.uk> GPG Key ID: 1DE9DE75
Web: <URL:http://ket.ch.cam.ac.uk/people/tow/index.html>
Tel: +44 1223 336423
Fax: +44 1223 336362


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