GSL on OS/2

[Henry Sobotka <sobotka at axess dot com>]

Got GSL 0.7 built on OS/2 this week with emx and pgcc 2.95.2. Running
check turned up five failures.

One is known:
FAIL: vegas(f1), dim=9, err=0.0026, chisq=138.4868 (0.98967811857786181
observed vs 1 expected)

The second is in monte, but not the known one (which is a PASS here):
FAIL: miser(f1), dim=6, err=0.0136 (0.95826097363903695 observed vs 1
expected)

The remaining three are Legendre tests:
FAIL:   gsl_sf_legendre_H3d_0_impl(1.0e-06, 1.0e-06, &r)
  ../../specfunc/test_legendre.c 244
  expected:   0.9999999999998334
  obtained:   0.9999999999998673   1.332267851594616e-15  1.33227e-15
  fracdiff: 1.698641227676744e-14
  value/expected not consistent within reported error
  value not within tolerance of expected value
    0.999999999999867328  1.3322678515946159e-15
FAIL:   gsl_sf_legendre_H3d_impl(5, 1.0, 1.0e-10, &r)
  ../../specfunc/test_legendre.c 270
  expected: 2.022491201695877e-52
  obtained: 2.022491205489096e-52   2.236646508965741e-65  1.10589e-13
  fracdiff: 9.377591586905552e-10
  value/expected not consistent within reported error
  value not within tolerance of expected value
  2.02249120548909587e-52  2.23664650896574144e-65
FAIL:   gsl_sf_legendre_H3d_impl(5, 1.0e+08, 1.0e-08, &r)
  ../../specfunc/test_legendre.c 284
  expected: 9.256115861125842e-05
  obtained: 9.256115860100377e-05   9.76454700231151e-18  1.05493e-13
  fracdiff: 5.539387038692824e-11
  value/expected not consistent within reported error
  value not within tolerance of expected value
  9.25611586010037735e-05  9.76454700231150969e-18

Didn't spot anything obvious in a quick stepthru, and plan to take a
closer look in the days/weeks ahead, as well as try linking with fdlibm
instead of our standard libm to see if that makes a diff. I'm also
playing around with optimization levels and other gcc flags (suggestions
welcome).

FWIW, -O6 gave me SIGSEGV in the specfunc test (after giving it more
than ample stackspace), six strange FAIL messages in vector:

FAIL: gsl_vector_complex_long_double_swap_elements exchanges elements
correctly 
FAIL: gsl_vector_complex_long_double_reverse reverses elements correctly 
FAIL: gsl_vector_complex_write and read work correctly 
FAIL: gsl_vector_complex_long_double_swap_elements (static) exchanges
elements correctly 
FAIL: gsl_vector_complex_long_double_reverse (static) reverses elements
correctly 
FAIL: gsl_vector_complex_write and read work correctly 

and eight failures in integration:

FAIL: qng(f1) smooth 43pt abserr (2.66689017835849249e-12 observed vs
2.6668930448662145e-12 expected) 
FAIL: qng(f1) reverse 43pt abserr (2.66688998720491599e-12 observed vs
2.6668930448662145e-12 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) 
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) 

I haven't yet determined what optimization level triggers these.

I have an fp-os2emx.c for ieee-utils and related
HAVE_OS2EMX_IEEE_INTERFACE patches for fp.c and config files. How do I
submit?

While gsl doesn't quite build out of the box, most are makefile fixes
that really belong in libtool (which I accidentally discovered this week
has OS/2 support though I've never seen it kick in during the past two
years or so since installation, and no one has yet come forward to claim
it "works here" in response to my sporadic grumbling about it in OS/2
developer forums). Apart from that, our libm is missing acosh and atanh,
and I haven't yet decided how best to handle that because we can get
them from either fdlibm or the POSIX/2 libextensions.

Much as the five flops bug me, out of some 60K+ test that works out to a
99.99% PASS rate. Great job, people!

h~