From mboxrd@z Thu Jan 1 00:00:00 1970 From: Toby White To: Brian Gough Cc: gsl-discuss@sources.redhat.com Subject: Re: gsl 0.8 compile error Date: Wed, 19 Dec 2001 13:20:00 -0000 Message-id: <87ithkdy2f.fsf@bit.ch.cam.ac.uk> References: <20010625162824.A10447@physics.hanyang.ac.kr> <15159.478.675073.342587@debian> <87ithkh3vq.fsf@bit.ch.cam.ac.uk> <15159.41618.817842.119459@debian> X-SW-Source: 2001/msg00248.html Brian Gough 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: GPG Key ID: 1DE9DE75 Web: Tel: +44 1223 336423 Fax: +44 1223 336362