test release gsl-1.8.90.tar.gz

test release gsl-1.8.90.tar.gz

[Brian Gough]

I have made a test release for gsl-1.9. 

I have only tested it on GNU/Linux -- please report any problems you
find in compiling it, running make check or against existing
applications (it should be backwards compatible).

It is available at the following location:

http://www.network-theory.co.uk/download/gsl/gsl-1.8.90.tar.gz
http://www.network-theory.co.uk/download/gsl/gsl-1.8.90.tar.gz.sig

The main new features from the ChangeLog are:

** Added support for nonsymmetric eigensystems (Patrick Alken)

** Added Mathieu functions (Lowell Johnson)

** Added a new BFGS2 minimisation method, requires substantially fewer
function and gradient evaluations that the existing BFGS minimiser.

** Added new functions for basis splines (Patrick Alken)

-- 
Brian Gough

Re: test release gsl-1.8.90.tar.gz

[Patrick Alken]

[-- Attachment #1: Type: text/plain, Size: 1617 bytes --]

Hi,

  I've compiled and make check'd it on:

GNU/Linux/AMD 2.6.14 and
NetBSD/i386 2.1

with no problems. I also compiled it under linux with the flags:

make CFLAGS="-pedantic -Wall -W -Wmissing-prototypes
-Wstrict-prototypes -Wconversion -Wshadow -Wpointer-arith -Wcast-qual
-Wcast-align -Wwrite-strings -Wnested-externs -fshort-enums -fno-common"

and I attached all the resulting warnings. They're all pretty
harmless. The only thing that stands out is there are a few cases
where local gsl variable names are shadowing global ones in
the system mathcalls.h.

I also stuck in a -ansi there and everything looks good under that
too except for a lot of complaining about no hypot prototype..

Anyway, its looking good!

Patrick Alken

On Thu, Feb 15, 2007 at 12:51:23PM +0000, Brian Gough wrote:
> I have made a test release for gsl-1.9. 
> 
> I have only tested it on GNU/Linux -- please report any problems you
> find in compiling it, running make check or against existing
> applications (it should be backwards compatible).
> 
> It is available at the following location:
> 
> http://www.network-theory.co.uk/download/gsl/gsl-1.8.90.tar.gz
> http://www.network-theory.co.uk/download/gsl/gsl-1.8.90.tar.gz.sig
> 
> The main new features from the ChangeLog are:
> 
> ** Added support for nonsymmetric eigensystems (Patrick Alken)
> 
> ** Added Mathieu functions (Lowell Johnson)
> 
> ** Added a new BFGS2 minimisation method, requires substantially fewer
> function and gradient evaluations that the existing BFGS minimiser.
> 
> ** Added new functions for basis splines (Patrick Alken)
> 
> -- 
> Brian Gough
> 

[-- Attachment #2: warnfile --]
[-- Type: text/plain, Size: 26869 bytes --]

view_source.c:34: warning: cast discards qualifiers from pointer target type
view_source.c:67: warning: cast discards qualifiers from pointer target type
view_source.c:34: warning: cast discards qualifiers from pointer target type
view_source.c:67: warning: cast discards qualifiers from pointer target type
view_source.c:34: warning: cast discards qualifiers from pointer target type
view_source.c:67: warning: cast discards qualifiers from pointer target type
view_source.c:34: warning: cast discards qualifiers from pointer target type
view_source.c:67: warning: cast discards qualifiers from pointer target type
view_source.c:34: warning: cast discards qualifiers from pointer target type
view_source.c:67: warning: cast discards qualifiers from pointer target type
view_source.c:34: warning: cast discards qualifiers from pointer target type
view_source.c:67: warning: cast discards qualifiers from pointer target type
view_source.c:34: warning: cast discards qualifiers from pointer target type
view_source.c:67: warning: cast discards qualifiers from pointer target type
view_source.c:34: warning: cast discards qualifiers from pointer target type
view_source.c:67: warning: cast discards qualifiers from pointer target type
view_source.c:34: warning: cast discards qualifiers from pointer target type
view_source.c:67: warning: cast discards qualifiers from pointer target type
view_source.c:34: warning: cast discards qualifiers from pointer target type
view_source.c:67: warning: cast discards qualifiers from pointer target type
view_source.c:34: warning: cast discards qualifiers from pointer target type
view_source.c:67: warning: cast discards qualifiers from pointer target type
view_source.c:34: warning: cast discards qualifiers from pointer target type
view_source.c:67: warning: cast discards qualifiers from pointer target type
view_source.c:34: warning: cast discards qualifiers from pointer target type
view_source.c:67: warning: cast discards qualifiers from pointer target type
view_source.c:34: warning: cast discards qualifiers from pointer target type
view_source.c:67: warning: cast discards qualifiers from pointer target type
view_source.c:40: warning: cast discards qualifiers from pointer target type
view_source.c:80: warning: cast discards qualifiers from pointer target type
view_source.c:40: warning: cast discards qualifiers from pointer target type
view_source.c:80: warning: cast discards qualifiers from pointer target type
view_source.c:40: warning: cast discards qualifiers from pointer target type
view_source.c:80: warning: cast discards qualifiers from pointer target type
view_source.c:40: warning: cast discards qualifiers from pointer target type
view_source.c:80: warning: cast discards qualifiers from pointer target type
view_source.c:40: warning: cast discards qualifiers from pointer target type
view_source.c:80: warning: cast discards qualifiers from pointer target type
view_source.c:40: warning: cast discards qualifiers from pointer target type
view_source.c:80: warning: cast discards qualifiers from pointer target type
view_source.c:40: warning: cast discards qualifiers from pointer target type
view_source.c:80: warning: cast discards qualifiers from pointer target type
view_source.c:40: warning: cast discards qualifiers from pointer target type
view_source.c:80: warning: cast discards qualifiers from pointer target type
view_source.c:40: warning: cast discards qualifiers from pointer target type
view_source.c:80: warning: cast discards qualifiers from pointer target type
view_source.c:40: warning: cast discards qualifiers from pointer target type
view_source.c:80: warning: cast discards qualifiers from pointer target type
view_source.c:40: warning: cast discards qualifiers from pointer target type
view_source.c:80: warning: cast discards qualifiers from pointer target type
view_source.c:40: warning: cast discards qualifiers from pointer target type
view_source.c:80: warning: cast discards qualifiers from pointer target type
view_source.c:40: warning: cast discards qualifiers from pointer target type
view_source.c:80: warning: cast discards qualifiers from pointer target type
view_source.c:40: warning: cast discards qualifiers from pointer target type
view_source.c:80: warning: cast discards qualifiers from pointer target type
blas.c:52: warning: passing arg 2 of `cblas_sdsdot' as `float' rather than `double' due to prototype
blas.c:393: warning: passing arg 2 of `cblas_saxpy' as `float' rather than `double' due to prototype
blas.c:474: warning: passing arg 6 of `cblas_srot' as `float' rather than `double' due to prototype
blas.c:474: warning: passing arg 7 of `cblas_srot' as `float' rather than `double' due to prototype
blas.c:504: warning: passing arg 4 of `cblas_srotmg' as `float' rather than `double' due to prototype
blas.c:554: warning: passing arg 2 of `cblas_sscal' as `float' rather than `double' due to prototype
blas.c:580: warning: passing arg 2 of `cblas_csscal' as `float' rather than `double' due to prototype
blas.c:609: warning: passing arg 5 of `cblas_sgemv' as `float' rather than `double' due to prototype
blas.c:609: warning: passing arg 10 of `cblas_sgemv' as `float' rather than `double' due to prototype
blas.c:762: warning: passing arg 4 of `cblas_ssymv' as `float' rather than `double' due to prototype
blas.c:762: warning: passing arg 9 of `cblas_ssymv' as `float' rather than `double' due to prototype
blas.c:987: warning: passing arg 4 of `cblas_sger' as `float' rather than `double' due to prototype
blas.c:1128: warning: passing arg 4 of `cblas_cher' as `float' rather than `double' due to prototype
blas.c:1225: warning: passing arg 4 of `cblas_ssyr' as `float' rather than `double' due to prototype
blas.c:1271: warning: passing arg 4 of `cblas_ssyr2' as `float' rather than `double' due to prototype
blas.c:1323: warning: passing arg 7 of `cblas_sgemm' as `float' rather than `double' due to prototype
blas.c:1323: warning: passing arg 12 of `cblas_sgemm' as `float' rather than `double' due to prototype
blas.c:1440: warning: passing arg 6 of `cblas_ssymm' as `float' rather than `double' due to prototype
blas.c:1440: warning: passing arg 11 of `cblas_ssymm' as `float' rather than `double' due to prototype
blas.c:1643: warning: passing arg 6 of `cblas_ssyrk' as `float' rather than `double' due to prototype
blas.c:1643: warning: passing arg 9 of `cblas_ssyrk' as `float' rather than `double' due to prototype
blas.c:1747: warning: passing arg 6 of `cblas_cherk' as `float' rather than `double' due to prototype
blas.c:1747: warning: passing arg 9 of `cblas_cherk' as `float' rather than `double' due to prototype
blas.c:1801: warning: passing arg 6 of `cblas_ssyr2k' as `float' rather than `double' due to prototype
blas.c:1801: warning: passing arg 11 of `cblas_ssyr2k' as `float' rather than `double' due to prototype
blas.c:1920: warning: passing arg 11 of `cblas_cher2k' as `float' rather than `double' due to prototype
blas.c:1975: warning: passing arg 8 of `cblas_strmm' as `float' rather than `double' due to prototype
blas.c:2094: warning: passing arg 8 of `cblas_strsm' as `float' rather than `double' due to prototype
tridiag.c:47: warning: declaration of 'gamma' shadows a global declaration
/usr/include/bits/mathcalls.h:265: warning: shadowed declaration is here
tridiag.c:207: warning: declaration of 'gamma' shadows a global declaration
/usr/include/bits/mathcalls.h:265: warning: shadowed declaration is here
hessenberg.c:289: warning: passing arg 2 of `gsl_matrix_set' as unsigned due to prototype
hessenberg.c:289: warning: passing arg 3 of `gsl_matrix_set' as unsigned due to prototype
hermv.c:223: warning: declaration of 'y1' shadows a global declaration
/usr/include/bits/mathcalls.h:242: warning: shadowed declaration is here
bessel.c:459: warning: declaration of 'gamma' shadows a global declaration
/usr/include/bits/mathcalls.h:265: warning: shadowed declaration is here
bessel_Jnu.c:152: warning: declaration of 'gamma' shadows a global declaration
/usr/include/bits/mathcalls.h:265: warning: shadowed declaration is here
bessel_olver.c:597: warning: unused parameter 'abs_zeta'
bessel_olver.c:629: warning: unused parameter 'abs_zeta'
bessel_olver.c:752: warning: unused parameter 'abs_zeta'
bessel_olver.c:781: warning: unused parameter 'abs_zeta'
bessel_y.c:46: warning: passing arg 1 of `gsl_sf_doublefact_e' as unsigned due to prototype
bessel_zero.c:1125: warning: passing arg 2 of `clenshaw' as signed due to prototype
bessel_zero.c:1133: warning: passing arg 2 of `clenshaw' as signed due to prototype
bessel_zero.c:1145: warning: passing arg 2 of `clenshaw' as signed due to prototype
bessel_zero.c:1153: warning: passing arg 2 of `clenshaw' as signed due to prototype
bessel_zero.c:1171: warning: passing arg 2 of `clenshaw' as signed due to prototype
coulomb.c:1138: warning: declaration of 'gamma' shadows a global declaration
/usr/include/bits/mathcalls.h:265: warning: shadowed declaration is here
coupling.c:66: warning: passing arg 1 of `gsl_sf_fact_e' as unsigned due to prototype
coupling.c:67: warning: passing arg 1 of `gsl_sf_fact_e' as unsigned due to prototype
coupling.c:68: warning: passing arg 1 of `gsl_sf_fact_e' as unsigned due to prototype
coupling.c:69: warning: passing arg 1 of `gsl_sf_fact_e' as unsigned due to prototype
coupling.c:142: warning: passing arg 1 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:142: warning: passing arg 2 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:143: warning: passing arg 1 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:143: warning: passing arg 2 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:144: warning: passing arg 1 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:144: warning: passing arg 2 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:145: warning: passing arg 1 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:145: warning: passing arg 2 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:146: warning: passing arg 1 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:146: warning: passing arg 2 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:147: warning: passing arg 1 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:147: warning: passing arg 2 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:157: warning: passing arg 1 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:157: warning: passing arg 2 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:158: warning: passing arg 1 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:158: warning: passing arg 2 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:159: warning: passing arg 1 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:159: warning: passing arg 2 of `gsl_sf_choose_e' as unsigned due to prototype
coupling.c:188: warning: no previous prototype for 'gsl_sf_coupling_6j_INCORRECT_e'
coupling.c:254: warning: passing arg 1 of `gsl_sf_fact_e' as unsigned due to prototype
coupling.c:255: warning: passing arg 1 of `gsl_sf_fact_e' as unsigned due to prototype
coupling.c:256: warning: passing arg 1 of `gsl_sf_fact_e' as unsigned due to prototype
coupling.c:257: warning: passing arg 1 of `gsl_sf_fact_e' as unsigned due to prototype
coupling.c:258: warning: passing arg 1 of `gsl_sf_fact_e' as unsigned due to prototype
coupling.c:259: warning: passing arg 1 of `gsl_sf_fact_e' as unsigned due to prototype
coupling.c:260: warning: passing arg 1 of `gsl_sf_fact_e' as unsigned due to prototype
coupling.c:261: warning: passing arg 1 of `gsl_sf_fact_e' as unsigned due to prototype
coupling.c:406: warning: no previous prototype for 'gsl_sf_coupling_6j_INCORRECT'
coulomb_bound.c:43: warning: passing arg 1 of `gsl_sf_lnfact_e' as unsigned due to prototype
coulomb_bound.c:44: warning: passing arg 1 of `gsl_sf_lnfact_e' as unsigned due to prototype
coulomb_bound.c:91: warning: passing arg 2 of `gsl_sf_laguerre_n_e' as floating rather than integer due to prototype
ellint.c:89: warning: declaration of 'yn' shadows a global declaration
/usr/include/bits/mathcalls.h:243: warning: shadowed declaration is here
ellint.c:128: warning: declaration of 'yn' shadows a global declaration
/usr/include/bits/mathcalls.h:243: warning: shadowed declaration is here
ellint.c:190: warning: declaration of 'yn' shadows a global declaration
/usr/include/bits/mathcalls.h:243: warning: shadowed declaration is here
ellint.c:244: warning: declaration of 'yn' shadows a global declaration
/usr/include/bits/mathcalls.h:243: warning: shadowed declaration is here
ellint.c:449: warning: declaration of 'rd' shadows a previous local
ellint.c:442: warning: shadowed declaration is here
ellint.c:426: warning: unused parameter 'n'
exp.c:453: warning: passing arg 1 of `gsl_sf_lnfact_e' as unsigned due to prototype
exp.c:471: warning: passing arg 1 of `gsl_sf_lnfact_e' as unsigned due to prototype
exp.c:472: warning: passing arg 1 of `log' as floating rather than integer due to prototype
fermi_dirac.c:1153: warning: passing arg 1 of `gsl_sf_fact_e' as unsigned due to prototype
fermi_dirac.c:1400: warning: passing arg 1 of `fd_neg' as floating rather than integer due to prototype
fermi_dirac.c:1410: warning: passing arg 1 of `fd_asymp' as floating rather than integer due to prototype
gamma.c:830: warning: passing arg 1 of `gsl_sf_lnfact_e' as unsigned due to prototype
gamma.c:1614: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
gamma_inc.c:152: warning: declaration of 'erfc' shadows a global declaration
/usr/include/bits/mathcalls.h:251: warning: shadowed declaration is here
hyperg_1F1.c:152: warning: passing arg 2 of `pow' as floating rather than integer due to prototype
hyperg_1F1.c:153: warning: passing arg 2 of `pow' as floating rather than integer due to prototype
hyperg_1F1.c:153: warning: passing arg 2 of `pow' as floating rather than integer due to prototype
hyperg_1F1.c:975: warning: passing arg 1 of `hyperg_1F1_beq2a_pos' as floating rather than integer due to prototype
hyperg_1F1.c:981: warning: passing arg 1 of `gsl_sf_hyperg_1F1_series_e' as floating rather than integer due to prototype
hyperg_1F1.c:981: warning: passing arg 2 of `gsl_sf_hyperg_1F1_series_e' as floating rather than integer due to prototype
hyperg_1F1.c:989: warning: passing arg 1 of `hyperg_1F1_CF1_p_ser' as floating rather than integer due to prototype
hyperg_1F1.c:989: warning: passing arg 2 of `hyperg_1F1_CF1_p_ser' as floating rather than integer due to prototype
hyperg_1F1.c:1003: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_1F1.c:1014: warning: passing arg 1 of `hyperg_1F1_CF1_p_ser' as floating rather than integer due to prototype
hyperg_1F1.c:1014: warning: passing arg 2 of `hyperg_1F1_CF1_p_ser' as floating rather than integer due to prototype
hyperg_1F1.c:1034: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_1F1.c:1057: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_1F1.c:1086: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_1F1.c:1113: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_1F1.c:1169: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_1F1.c:1204: warning: passing arg 1 of `sqrt' as floating rather than integer due to prototype
hyperg_1F1.c:1233: warning: passing arg 1 of `gsl_sf_lnfact_e' as unsigned due to prototype
hyperg_1F1.c:1246: warning: passing arg 2 of `gsl_sf_lnbeta_e' as floating rather than integer due to prototype
hyperg_1F1.c:1255: warning: passing arg 2 of `gsl_sf_beta_e' as floating rather than integer due to prototype
hyperg_1F1.c:1267: warning: passing arg 1 of `log' as floating rather than integer due to prototype
hyperg_1F1.c:1317: warning: passing arg 2 of `hyperg_1F1_a_negint_poly' as floating rather than integer due to prototype
hyperg_1F1.c:1326: warning: passing arg 2 of `hyperg_1F1_a_negint_poly' as floating rather than integer due to prototype
hyperg_1F1.c:1813: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_1F1.c:1813: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_1F1.c:1815: warning: passing arg 1 of `hyperg_1F1_asymp_posx' as floating rather than integer due to prototype
hyperg_1F1.c:1815: warning: passing arg 2 of `hyperg_1F1_asymp_posx' as floating rather than integer due to prototype
hyperg_1F1.c:1817: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_1F1.c:1817: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_1F1.c:1819: warning: passing arg 1 of `hyperg_1F1_asymp_negx' as floating rather than integer due to prototype
hyperg_1F1.c:1819: warning: passing arg 2 of `hyperg_1F1_asymp_negx' as floating rather than integer due to prototype
hyperg_U.c:285: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_U.c:470: warning: declaration of 'xi' shadows a previous local
hyperg_U.c:388: warning: shadowed declaration is here
hyperg_U.c:532: warning: declaration of 'xi' shadows a previous local
hyperg_U.c:388: warning: shadowed declaration is here
hyperg_U.c:699: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_U.c:709: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_U.c:713: warning: passing arg 1 of `hyperg_zaU_asymp' as floating rather than integer due to prototype
hyperg_U.c:713: warning: passing arg 2 of `hyperg_zaU_asymp' as floating rather than integer due to prototype
hyperg_U.c:719: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_U.c:719: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_U.c:721: warning: passing arg 1 of `hyperg_U_series' as floating rather than integer due to prototype
hyperg_U.c:721: warning: passing arg 2 of `hyperg_U_series' as floating rather than integer due to prototype
hyperg_U.c:751: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_U.c:764: warning: passing arg 2 of `hyperg_U_small_a_bgt0' as floating rather than integer due to prototype
hyperg_U.c:785: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_U.c:815: warning: passing arg 1 of `hyperg_U_CF1' as floating rather than integer due to prototype
hyperg_U.c:815: warning: passing arg 2 of `hyperg_U_CF1' as floating rather than integer due to prototype
hyperg_U.c:836: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_U.c:868: warning: passing arg 1 of `hyperg_U_CF1' as floating rather than integer due to prototype
hyperg_U.c:868: warning: passing arg 2 of `hyperg_U_CF1' as floating rather than integer due to prototype
hyperg_U.c:880: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_U.c:902: warning: passing arg 1 of `hyperg_lnU_beq2a' as floating rather than integer due to prototype
hyperg_U.c:932: warning: passing arg 1 of `hyperg_U_small_a_bgt0' as floating rather than integer due to prototype
hyperg_U.c:932: warning: passing arg 2 of `hyperg_U_small_a_bgt0' as floating rather than integer due to prototype
hyperg_U.c:946: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_U.c:1004: warning: passing arg 1 of `gsl_sf_lnfact_e' as unsigned due to prototype
hyperg_U.c:1277: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_U.c:1314: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
hyperg_U.c:1346: warning: passing arg 1 of `gsl_sf_hyperg_U_int_e10_e' as integer rather than floating due to prototype
hyperg_U.c:1346: warning: passing arg 2 of `gsl_sf_hyperg_U_int_e10_e' as integer rather than floating due to prototype
laguerre.c:60: warning: passing arg 1 of `gsl_sf_lnfact_e' as unsigned due to prototype
laguerre.c:94: warning: passing arg 1 of `gsl_sf_lnfact_e' as unsigned due to prototype
legendre_H3d.c:466: warning: passing arg 2 of `hypot' as floating rather than integer due to prototype
legendre_H3d.c:537: warning: passing arg 2 of `hypot' as floating rather than integer due to prototype
legendre_Qn.c:294: warning: passing arg 1 of `legendre_Ql_asymp_unif' as floating rather than integer due to prototype
legendre_con.c:104: warning: passing arg 1 of `sqrt' as floating rather than integer due to prototype
legendre_con.c:124: warning: declaration of 'gamma' shadows a global declaration
/usr/include/bits/mathcalls.h:265: warning: shadowed declaration is here
legendre_con.c:143: warning: passing arg 1 of `sqrt' as floating rather than integer due to prototype
legendre_poly.c:542: warning: passing arg 1 of `gsl_sf_lnpoch_e' as floating rather than integer due to prototype
legendre_poly.c:544: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
legendre_poly.c:582: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
legendre_poly.c:625: warning: passing arg 1 of `gsl_sf_lnpoch_e' as floating rather than integer due to prototype
mathieu_charv.c:695: warning: comparison between signed and unsigned
mathieu_charv.c:773: warning: comparison between signed and unsigned
mathieu_charv.c:791: warning: comparison between signed and unsigned
mathieu_charv.c:843: warning: comparison between signed and unsigned
poch.c:163: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
poch.c:178: warning: passing arg 1 of `fabs' as floating rather than integer due to prototype
psi.c:527: warning: passing arg 2 of `gsl_complex_add_real' as floating rather than integer due to prototype
psi.c:593: warning: passing arg 1 of `log' as floating rather than integer due to prototype
psi.c:594: warning: passing arg 1 of `log' as floating rather than integer due to prototype
zeta.c:935: warning: passing arg 1 of `gsl_sf_zetam1_e' as floating rather than integer due to prototype
niederreiter-2.c:78: warning: unused parameter 'dimension'
sobol.c:129: warning: unused parameter 'dimension'
gausszig.c:187: warning: declaration of 'y0' shadows a global declaration
/usr/include/bits/mathcalls.h:241: warning: shadowed declaration is here
gausszig.c:187: warning: declaration of 'y1' shadows a global declaration
/usr/include/bits/mathcalls.h:242: warning: shadowed declaration is here
binomial_tpe.c:81: warning: declaration of 'y1' shadows a global declaration
/usr/include/bits/mathcalls.h:242: warning: shadowed declaration is here
binomial_tpe.c:120: warning: passing arg 2 of `gsl_pow_int' as signed due to prototype
siman_tsp.c:90: warning: declaration of 'y1' shadows a global declaration
/usr/include/bits/mathcalls.h:242: warning: shadowed declaration is here
linear.c:28: warning: unused parameter 'vstate'
linear.c:29: warning: unused parameter 'x_array'
linear.c:30: warning: unused parameter 'y_array'
linear.c:31: warning: unused parameter 'size'
linear.c:38: warning: unused parameter 'vstate'
linear.c:79: warning: unused parameter 'vstate'
linear.c:122: warning: unused parameter 'vstate'
linear.c:123: warning: unused parameter 'x_array'
linear.c:123: warning: unused parameter 'y_array'
linear.c:123: warning: unused parameter 'size'
linear.c:124: warning: unused parameter 'x'
linear.c:125: warning: unused parameter 'a'
linear.c:136: warning: unused parameter 'vstate'
poly.c:89: warning: unused parameter 'ya'
poly.c:90: warning: unused parameter 'acc'
poly.c:102: warning: unused parameter 'ya'
poly.c:103: warning: unused parameter 'acc'
poly.c:116: warning: unused parameter 'ya'
poly.c:117: warning: unused parameter 'acc'
poly.c:143: warning: passing arg 2 of `pow' as floating rather than integer due to prototype
poly.c:143: warning: passing arg 2 of `pow' as floating rather than integer due to prototype
poly.c:129: warning: unused parameter 'ya'
poly.c:130: warning: unused parameter 'acc'
rk2imp.c:129: warning: declaration of 'y0' shadows a global declaration
/usr/include/bits/mathcalls.h:241: warning: shadowed declaration is here
rk2imp.c:185: warning: declaration of 'y0' shadows a global declaration
/usr/include/bits/mathcalls.h:241: warning: shadowed declaration is here
rk2simp.c:175: warning: declaration of 'y0' shadows a global declaration
/usr/include/bits/mathcalls.h:241: warning: shadowed declaration is here
rk2simp.c:258: warning: declaration of 'y0' shadows a global declaration
/usr/include/bits/mathcalls.h:241: warning: shadowed declaration is here
rk2simp.c:251: warning: unused parameter 'dydt_in'
rk4imp.c:234: warning: declaration of 'y0' shadows a global declaration
/usr/include/bits/mathcalls.h:241: warning: shadowed declaration is here
gear1.c:118: warning: declaration of 'y0' shadows a global declaration
/usr/include/bits/mathcalls.h:241: warning: shadowed declaration is here
gear1.c:160: warning: declaration of 'y0' shadows a global declaration
/usr/include/bits/mathcalls.h:241: warning: shadowed declaration is here
gear1.c:152: warning: unused parameter 'dydt_in'
gear2.c:143: warning: declaration of 'y0' shadows a global declaration
/usr/include/bits/mathcalls.h:241: warning: shadowed declaration is here
gear2.c:217: warning: declaration of 'y0' shadows a global declaration
/usr/include/bits/mathcalls.h:241: warning: shadowed declaration is here
directional_minimize.c:36: warning: unused parameter 'stepa'
directional_minimize.c:36: warning: unused parameter 'stepa'
directional_minimize.c:36: warning: unused parameter 'stepa'
linear_minimize.c:76: warning: ISO C90 forbids mixed declarations and code
linear_minimize.c:202: warning: ISO C90 forbids mixed declarations and code
vector_bfgs2.c:207: warning: unused parameter 'fdf'
simplex.c:101: warning: declaration of 'y1' shadows a global declaration
/usr/include/bits/mathcalls.h:242: warning: shadowed declaration is here
simplex.c:287: warning: declaration of 'y1' shadows a global declaration
/usr/include/bits/mathcalls.h:242: warning: shadowed declaration is here
hypergeometric.c:60: warning: passing arg 1 of `gsl_ran_hypergeometric_pdf' as unsigned due to prototype
gsl-randist.c:90: warning: string length `570' is greater than the length `509' ISO C89 compilers are required to support

Re: test release gsl-1.8.90.tar.gz

[Ed Smith-Rowland]

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

Brian Gough wrote:
> I have made a test release for gsl-1.9. 
>
> I have only tested it on GNU/Linux -- please report any problems you
> find in compiling it, running make check or against existing
> applications (it should be backwards compatible).
>
> It is available at the following location:
>
> http://www.network-theory.co.uk/download/gsl/gsl-1.8.90.tar.gz
> http://www.network-theory.co.uk/download/gsl/gsl-1.8.90.tar.gz.sig
>
> The main new features from the ChangeLog are:
>
> ** Added support for nonsymmetric eigensystems (Patrick Alken)
>
> ** Added Mathieu functions (Lowell Johnson)
>
> ** Added a new BFGS2 minimisation method, requires substantially fewer
> function and gradient evaluations that the existing BFGS minimiser.
>
> ** Added new functions for basis splines (Patrick Alken)
>
>   
I tested on Mac OS X / 10.3.9 PPC G4.
Everything came out good except the wavelet and spline stuff.

I am attaching the log.

I'll go back and test 1.8 tomorrow.

Also, what references are you looking at for restricting the angles in 
the elliptic integrals?
I am in the middle of implementing special functions for gcc (The C++ 
standards people are adding a list of special functions to the library - 
or rather to an adjunct of the library.)

Finally, how do you get Hermite polynomials out of GSL?

Thank you,

Ed Smith-Rowland


[-- Attachment #2: log.bz2 --]
[-- Type: application/octet-stream, Size: 7798 bytes --]

Re: test release gsl-1.8.90.tar.gz

[Yoshiki TSUNESADA]

 I tested on cygwin 1.5.23 + gcc 3.4.4, and found no
 problems in "./configure; make". No FAILs are found
 in "make check".

>I have made a test release for gsl-1.9. 
>
>I have only tested it on GNU/Linux -- please report any problems you
>find in compiling it, running make check or against existing
>applications (it should be backwards compatible).
>
>It is available at the following location:
>
>http://www.network-theory.co.uk/download/gsl/gsl-1.8.90.tar.gz
>http://www.network-theory.co.uk/download/gsl/gsl-1.8.90.tar.gz.sig
>
>The main new features from the ChangeLog are:
>
>** Added support for nonsymmetric eigensystems (Patrick Alken)
>
>** Added Mathieu functions (Lowell Johnson)
>
>** Added a new BFGS2 minimisation method, requires substantially fewer
>function and gradient evaluations that the existing BFGS minimiser.
>
>** Added new functions for basis splines (Patrick Alken)
>
>-- 
>Brian Gough

Re: test release gsl-1.8.90.tar.gz

[Tim Fenn]

On Thu, Feb 15, 2007 at 12:51:23PM +0000, Brian Gough wrote:
> I have made a test release for gsl-1.9. 
> 
> I have only tested it on GNU/Linux -- please report any problems you
> find in compiling it, running make check or against existing
> applications (it should be backwards compatible).
> 

I've been testing the bfgs2 minimizer, and it works well until/if it
nears a point in which the interpolator stops progressing - I've
noticed there is a check against this in the linear_minimize code near
line 209:

      if ((a-alpha)*fpa <= GSL_DBL_EPSILON) {
        /* roundoff prevents progress */
      };

perhaps there should be a break statement to prevent futile
iterations?  Or use this as a stopping criteria test?

Regards,
Tim

Re: test release gsl-1.8.90.tar.gz

[Jari Häkkinen]

I have tested on Mac OSX 10.4.8 (Intel) with gcc v4.0.1.

./configure ; make ; make check

works perfectly. Browsing through the output shows no strange output.


Cheers,

Jari


Brian Gough wrote:
> I have made a test release for gsl-1.9. 
> 
> I have only tested it on GNU/Linux -- please report any problems you
> find in compiling it, running make check or against existing
> applications (it should be backwards compatible).
> 
> It is available at the following location:
> 
> http://www.network-theory.co.uk/download/gsl/gsl-1.8.90.tar.gz
> http://www.network-theory.co.uk/download/gsl/gsl-1.8.90.tar.gz.sig
> 
> The main new features from the ChangeLog are:
> 
> ** Added support for nonsymmetric eigensystems (Patrick Alken)
> 
> ** Added Mathieu functions (Lowell Johnson)
> 
> ** Added a new BFGS2 minimisation method, requires substantially fewer
> function and gradient evaluations that the existing BFGS minimiser.
> 
> ** Added new functions for basis splines (Patrick Alken)
> 

Re: test release gsl-1.8.90.tar.gz

[Leopold Palomo Avellaneda]

[-- Attachment #1: Type: text/plain, Size: 430 bytes --]

A Divendres 16 Febrer 2007 00:24, Patrick Alken va escriure:
> Hi,
>
>   I've compiled and make check'd it on:
>
> GNU/Linux/AMD 2.6.14 and

for you AMD is refering to AMD 64 bits?

if not, I will try to compile it in a 64 bits arch.

Otherwise, the best test IMHO is when the debian package was update and 
compiled in all the arch of debian.
Regards,

Leo
-- 
--
Linux User 152692
PGP: 0xF944807E
Catalonia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: test release gsl-1.8.90.tar.gz

[Patrick Alken]

On Fri, Feb 16, 2007 at 09:24:22AM +0100, Leopold Palomo Avellaneda wrote:
> A Divendres 16 Febrer 2007 00:24, Patrick Alken va escriure:
> > Hi,
> >
> >   I've compiled and make check'd it on:
> >
> > GNU/Linux/AMD 2.6.14 and
> 
> for you AMD is refering to AMD 64 bits?
> 
> if not, I will try to compile it in a 64 bits arch.

No, 32 bit amd.

Patrick Alken

Re: test release gsl-1.8.90.tar.gz

[Linas Vepstas]

On Fri, Feb 16, 2007 at 12:03:08AM -0500, Ed Smith-Rowland wrote:
> I am in the middle of implementing special functions for gcc (The C++ 
> standards people are adding a list of special functions to the library - 
> or rather to an adjunct of the library.)

Are you doing this by copying code from GSL, or is this an all-new
implementation? I'd hate to see an all-new implementation become part 
of the standard; C++ has a history of wrecking things and so remarks
like this make me nervous. (For example, the complex math type has been 
wrecked for half a decade, and I find it amazing that no effort has 
been made to fix it or make it operate in a compatible fashion. This
is one reason I've stopped using C++ for mathematics; unfortunately,
I still have a raft of old code, and so I continue to feel the pain.)

--lnas

test failure -- [was Re: test release gsl-1.8.90.tar.gz]

[Linas Vepstas]

Hi,

> > 
> > http://www.network-theory.co.uk/download/gsl/gsl-1.8.90.tar.gz

tried this on a powerpc power5 system, make check fails:

make  check-TESTS
make[2]: Entering directory `/kernels/tools/gsl-1.8.90/vector'
FAIL: gsl_vector_char_ispos on negative vector stride=1, N=10 [518]
FAIL: gsl_vector_char_isneg on negative vector stride=1, N=10 [519]
FAIL: gsl_vector_char_ispos on negative vector stride=2, N=10 [1295]
FAIL: gsl_vector_char_isneg on negative vector stride=2, N=10 [1296]

etc.
FAIL: test
etc.
FAIL: test_static
===================
2 of 2 tests failed
===================
make[2]: *** [check-TESTS] Error 1
make[2]: Leaving directory `/kernels/tools/gsl-1.8.90/vector'

Above is for  gcc --version
gcc (GCC) 4.1.0 (SUSE Linux)

 as --version
GNU assembler 2.16.91.0.5 20051219 (SUSE Linux)

for SuSE SLES10 on a power5 pSeries machine, compiled in 32-bit mode.

I wasn't able to immediately determine what the problem was.
Aren't chars always unsigned, and therefore can't be negative?
Yet the test case seems to be trying to assign a negative value
to a char, unless I misunderstood the testcase.

I'll try again in 64-bit mode shortly.

--linas

Re: test failure -- [was Re: test release gsl-1.8.90.tar.gz]

[Linas Vepstas]

On Fri, Feb 16, 2007 at 11:05:00AM -0600, Linas Vepstas wrote:
> 
> > > http://www.network-theory.co.uk/download/gsl/gsl-1.8.90.tar.gz
> 
> tried this on a powerpc power5 system, make check fails:
> 
> make  check-TESTS
> make[2]: Entering directory `/kernels/tools/gsl-1.8.90/vector'
> FAIL: gsl_vector_char_ispos on negative vector stride=1, N=10 [518]
> FAIL: gsl_vector_char_isneg on negative vector stride=1, N=10 [519]
> FAIL: gsl_vector_char_ispos on negative vector stride=2, N=10 [1295]
> FAIL: gsl_vector_char_isneg on negative vector stride=2, N=10 [1296]
> 
> etc.
> FAIL: test
> etc.
> FAIL: test_static
> ===================
> 2 of 2 tests failed
> ===================
> make[2]: *** [check-TESTS] Error 1
> make[2]: Leaving directory `/kernels/tools/gsl-1.8.90/vector'
> 
> Above is for  gcc --version
> gcc (GCC) 4.1.0 (SUSE Linux)
> 
>  as --version
> GNU assembler 2.16.91.0.5 20051219 (SUSE Linux)
> 
> for SuSE SLES10 on a power5 pSeries machine, compiled in 32-bit mode.
> 
> I wasn't able to immediately determine what the problem was.
> Aren't chars always unsigned, and therefore can't be negative?
> Yet the test case seems to be trying to assign a negative value
> to a char, unless I misunderstood the testcase.
> 
> I'll try again in 64-bit mode shortly.

I get the same errors when compiling for 64-bit 
(./configure CFLAGS=-m64)

--linas

Re: test release gsl-1.8.90.tar.gz

[Leopold Palomo Avellaneda]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

A Divendres 16 Febrer 2007 15:30, Patrick Alken va escriure:
> On Fri, Feb 16, 2007 at 09:24:22AM +0100, Leopold Palomo Avellaneda wrote:
> > A Divendres 16 Febrer 2007 00:24, Patrick Alken va escriure:
> > > Hi,
> > >
> > >   I've compiled and make check'd it on:
> > >
> > > GNU/Linux/AMD 2.6.14 and
> >
> > for you AMD is refering to AMD 64 bits?
> >
> > if not, I will try to compile it in a 64 bits arch.
I have compiled it on a GNU/Linux Debian Pre Etch amd64 with :

gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

and all test have been passed. So I suspect that in all emt extensions will 
work too.

Regards,

Leo


-- 
--
Linux User 152692
PGP: 0xF944807E
Catalonia

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: test release gsl-1.8.90.tar.gz

[Brian Gough]

At Thu, 15 Feb 2007 16:24:37 -0700,
Patrick Alken wrote:
>   I've compiled and make check'd it on:
> 
> GNU/Linux/AMD 2.6.14 and
> NetBSD/i386 2.1
> 
> with no problems. 

Thanks.


> I also stuck in a -ansi there and everything looks good under that
> too except for a lot of complaining about no hypot prototype..
> 

I think running configure with equivalent -ansi options should set the
HAVE_HYPOT definition to 0 in config.h, to avoid referencing it
directly.

-- 
Brian Gough

Re: test release gsl-1.8.90.tar.gz

[Brian Gough]

At Fri, 16 Feb 2007 00:03:08 -0500,
Ed Smith-Rowland wrote:
> I tested on Mac OS X / 10.3.9 PPC G4.
> Everything came out good except the wavelet and spline stuff.

Hello,

I think that one is a bug in the Mac OS X version of gcc - I have
never understood why it occurs. There's a note in the INSTALL file
that compiling with lower optimisation makes it go away.

> Also, what references are you looking at for restricting the angles in 
> the elliptic integrals?
> I am in the middle of implementing special functions for gcc (The C++ 
> standards people are adding a list of special functions to the library - 
> or rather to an adjunct of the library.)

I used Abramowitz & Stegun for the reduction formula.  Gerard
Jungman's original implementation of the elliptic integrals is based
on the Carlson paper mentioned in ellint.c.

> Finally, how do you get Hermite polynomials out of GSL?

We don't have any functions for Hermite Polynomials at the moment.

-- 
Brian Gough

Network Theory Ltd,
Publishing Free Software Manuals --- http://www.network-theory.co.uk/

Re: test release gsl-1.8.90.tar.gz

[Brian Gough]

At Fri, 16 Feb 2007 00:09:34 -0800,
Tim Fenn wrote:
> I've been testing the bfgs2 minimizer, and it works well until/if it
> nears a point in which the interpolator stops progressing - I've
> noticed there is a check against this in the linear_minimize code near
> line 209:
> 
>       if ((a-alpha)*fpa <= GSL_DBL_EPSILON) {
>         /* roundoff prevents progress */
>       };
> 
> perhaps there should be a break statement to prevent futile
> iterations?  Or use this as a stopping criteria test?

Thanks, there should be a 

        return GSL_ENOPROG;

in there.  You might want to try that and see if it stops at an
acceptable place.

Re: test failure -- [was Re: test release gsl-1.8.90.tar.gz]

[Brian Gough]

At Fri, 16 Feb 2007 11:45:39 -0600,
Linas Vepstas wrote:
> > make[2]: Entering directory `/kernels/tools/gsl-1.8.90/vector'
> > FAIL: gsl_vector_char_ispos on negative vector stride=1, N=10 [518]
> > FAIL: gsl_vector_char_isneg on negative vector stride=1, N=10 [519]
> > FAIL: gsl_vector_char_ispos on negative vector stride=2, N=10 [1295]
> > FAIL: gsl_vector_char_isneg on negative vector stride=2, N=10 [1296]
> > 
> > I wasn't able to immediately determine what the problem was.
> > Aren't chars always unsigned, and therefore can't be negative?
> > Yet the test case seems to be trying to assign a negative value
> > to a char, unless I misunderstood the testcase.

Thanks, I overlooked that.  char is unsigned on Power, signed on
intel.  I will make a note to run all the tests with -funsigned-char
as well in future.

-- 
Brian Gough

Network Theory Ltd,
Publishing Free Software Manuals --- http://www.network-theory.co.uk/

Re: test release gsl-1.8.90.tar.gz

[Dirk Eddelbuettel]

Following my upload of 1.8.90 to Debian unstable, results from the
autobuilders are available at the usual place:

	http://buildd.debian.org/gsl

All longs good, though I don't let it fail on test failure so someone could
write a quick wget/grep or perl hack to fetch the logs from that page to look
for anomalies.   i386 is missing as I uploaded the binary from my box.

Cheers, Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
                                                  -- Thomas A. Edison

Re: test release gsl-1.8.90.tar.gz

[Ed Smith-Rowland]

Linas Vepstas wrote:
> On Fri, Feb 16, 2007 at 12:03:08AM -0500, Ed Smith-Rowland wrote:
>   
>> I am in the middle of implementing special functions for gcc (The C++ 
>> standards people are adding a list of special functions to the library - 
>> or rather to an adjunct of the library.)
>>     
>
> Are you doing this by copying code from GSL, or is this an all-new
> implementation? I'd hate to see an all-new implementation become part 
> of the standard; C++ has a history of wrecking things and so remarks
> like this make me nervous. (For example, the complex math type has been 
> wrecked for half a decade, and I find it amazing that no effort has 
> been made to fix it or make it operate in a compatible fashion. This
> is one reason I've stopped using C++ for mathematics; unfortunately,
> I still have a raft of old code, and so I continue to feel the pain.)
>
> --lnas
>
>   
There are very large portions either from GSL or from the same sources 
as GSL uses (Abramowitz & Stegun, Olver, ..).
Construction of a special function library is just too difficult to do 
from scratch without leveraging the efforts of others where possible.

The portion of the C++ standard (actually a technical report - TR1) is 
here: TR1 
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf>
The relevant sections are 5 - special functions and a random number 
generator.  Also section 8 is C99 compatibility.  They deliberately 
adopted a C99 style calling convention to leave open the possibility 
that C99 could adopt this too.

The implementation of special functions for GCC should appear in 
mainline within a week or two.  The random number generator and almost 
all of the C99 compatibility parts are already in.  These should be 
released with gcc-4.3.

Concerning complex I swore that conforming C++ was supposed to store the 
real and imaginary parts in such a way that you could interact with 
C99.  I *think* you should be able to cast back and forth and have it 
work.  Also, a large part of this TR1 deals with syncing C99 with C++ 
(section 8).

I thought there was a way you could grab the raw implementation and use 
it in C99 and conversely put a C99 _Complex in a constructor for C++ 
complex.
I'll dig around and see.

Ed Smith-Rowland

Re: test release gsl-1.8.90.tar.gz

[Tim Fenn]

On Fri, Feb 16, 2007 at 09:25:30PM +0000, Brian Gough wrote:
> At Fri, 16 Feb 2007 00:09:34 -0800,
> Tim Fenn wrote:
> > I've been testing the bfgs2 minimizer, and it works well until/if it
> > nears a point in which the interpolator stops progressing - I've
> > noticed there is a check against this in the linear_minimize code near
> > line 209:
> > 
> >       if ((a-alpha)*fpa <= GSL_DBL_EPSILON) {
> >         /* roundoff prevents progress */
> >       };
> > 
> > perhaps there should be a break statement to prevent futile
> > iterations?  Or use this as a stopping criteria test?
> 
> Thanks, there should be a 
> 
>         return GSL_ENOPROG;
> 
> in there.  You might want to try that and see if it stops at an
> acceptable place.

That helps, yes.  It also might be worthwhile to note the bfgs2
minimizer requires positive step_size values (which makes intuitive
sense, but is not true of the bfgs/cgpr/cgfr minimizers).

Regards,
Tim

-- 
---------------------------------------------------------

        Tim Fenn
        fenn@stanford.edu
        Stanford University, School of Medicine
        James H. Clark Center
        318 Campus Drive, Room E300
        Stanford, CA  94305-5432
        Phone:  (650) 736-1714
        FAX:  (650) 736-1961

---------------------------------------------------------

Re: test release gsl-1.8.90.tar.gz

[Brian Gough]

At Tue, 20 Feb 2007 01:14:15 -0800,
Tim Fenn wrote:
> That helps, yes.  It also might be worthwhile to note the bfgs2
> minimizer requires positive step_size values (which makes intuitive
> sense, but is not true of the bfgs/cgpr/cgfr minimizers).

Thanks, I've made it take fabs(step_size).

-- 
Brian Gough

Network Theory Ltd,
Publishing Free Software Manuals --- http://www.network-theory.co.uk/

Re: test release gsl-1.8.90.tar.gz

[Gerard Jungman]

On Sat, 2007-02-17 at 10:08 -0500, Ed Smith-Rowland wrote:

> The portion of the C++ standard (actually a technical report - TR1) is 
> here: TR1 
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf>
> The relevant sections are 5 - special functions and a random number 
> generator.  Also section 8 is C99 compatibility.  They deliberately 
> adopted a C99 style calling convention to leave open the possibility 
> that C99 could adopt this too.

Hi. Thanks for the link. I hadn't seen this document until now.
I heard about this push for special functions from Walter Brown
(at FNAL) and we talked briefly about it once or twice in the
last few years.

I admire the effort going into this, but I have my doubts that it
is a good idea. For example, I was strongly against the inclusion
of the confluent hypergeometric function. The implementation in
GSL is a failed experiment, in my view (I wrote the implementation,
so I take full responsibility for that). The function itself is
too complicated. Even if it can be made to work reliably
over the whole domain, the resulting code would probabyl have
highly variable performance and/or be so heterogeneous that it
would just feel wrong, as a standard component.

This is one example, but there is a general problem here,
which is the illusion of simplicity that this type of
function provides. An interface of the form "given x and y,
return f(x,y)" can never express the many choices that have
to be made in the implementation. A good library needs to
expose these choices in some way; it need not be easy, but
it should at least be possible, for a knowledgeable client
to access these choices.

As another example of the inherent problems in this business,
consider the elliptic integrals. TR1 specifies the usual
first, second, and third kind functions, the way they
appear in textbooks. GSL includes these, but prefers
the Carlson forms. Carlson's book made it clear to me
that his forms are the most logical and are the best
for numerical implementation. Experts agree.

The general point is that the idea of "elliptic integrals"
is not just a couple of functions, it is really a family
of functions, joined together by a single algorithmic
idea, the arithmetic-geometric-mean. A good library
should express this.

I could go on for a while about this. But here is a
simple summary of my feeling about the TR1 special
functions:

  functions from TR1 that are simple enough
  that they could work as standard components
  -------------------------------------------
  beta function
  exponential integral
  riemann zeta
  

  functions that are doubtful as standard components
  --------------------------------------------------
  all the Bessel variants
  Laguerre
  Legendre
  Hermite
  elliptic integrals


  functions that will almost certainly fail as standard components
  ----------------------------------------------------------------
  hypergeometric functions, confluent and otherwise


Here is a final philosophical rant.
It is easy to see why elementary functions should be standard
components, regardless of the level of complexity in their
implementation. Thankfully, they are simple enough. It is
possible to argue that the gamma function should be a standard
component, but I think the only reason this holds up is that
we have the Lanczos algorithm. Without Lanczos, the gamma
function might be some hairy beast, requiring trade-offs 
that would complexify it beyond the realm of standard
components. By the time we get to the confluent hypergeometric
function, we are way out in a specialized problem domain,
where trade-offs and details become key to a successful
library implementation. Such functions have no place
as standard components.

Does anybody have use cases for things like confluent
hypergeometric? Who needs these functions, why do they need
them, and how do they expect to use them? 

Sorry to be so negative. Maybe you can tell me why I'm crazy.


> Concerning complex I swore that conforming C++ was supposed to store the 
> real and imaginary parts in such a way that you could interact with 
> C99.  I *think* you should be able to cast back and forth and have it 
> work.  Also, a large part of this TR1 deals with syncing C99 with C++ 
> (section 8).

> I thought there was a way you could grab the raw implementation and use 
> it in C99 and conversely put a C99 _Complex in a constructor for C++ 
> complex.
> I'll dig around and see.

As it does for Linas, this has bothered me for years. At this point
I have no idea what the standards (or anybody else for that matter)
can guarantee about compatibility between std::complex and C99 complex.
As far as I could tell previously, there was no way to make it
work reliably, although it probably works by default with gcc on
most platforms. Please do dig around and let us know what you find.

Thanks.
--
Gerard Jungman

Re: test release gsl-1.8.90.tar.gz

[Ed Smith-Rowland]

Gerard Jungman wrote:
> On Sat, 2007-02-17 at 10:08 -0500, Ed Smith-Rowland wrote:
>
>   
>> The portion of the C++ standard (actually a technical report - TR1) is 
>> here: TR1 
>> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf>
>> The relevant sections are 5 - special functions and a random number 
>> generator.  Also section 8 is C99 compatibility.  They deliberately 
>> adopted a C99 style calling convention to leave open the possibility 
>> that C99 could adopt this too.
>>     
>
> Hi. Thanks for the link. I hadn't seen this document until now.
> I heard about this push for special functions from Walter Brown
> (at FNAL) and we talked briefly about it once or twice in the
> last few years.
>
> I admire the effort going into this, but I have my doubts that it
> is a good idea. For example, I was strongly against the inclusion
> of the confluent hypergeometric function. The implementation in
> GSL is a failed experiment, in my view (I wrote the implementation,
> so I take full responsibility for that). The function itself is
> too complicated. Even if it can be made to work reliably
> over the whole domain, the resulting code would probabyl have
> highly variable performance and/or be so heterogeneous that it
> would just feel wrong, as a standard component.
>   
I am struggling over the hypergeometric functions as we speak. :-p
I was just wondering whether/what I could learn from the GSL.  I did 
detect a hint of desperation in the comments ;-).
The branching everywhere is also painful.
> This is one example, but there is a general problem here,
> which is the illusion of simplicity that this type of
> function provides. An interface of the form "given x and y,
> return f(x,y)" can never express the many choices that have
> to be made in the implementation. A good library needs to
> expose these choices in some way; it need not be easy, but
> it should at least be possible, for a knowledgeable client
> to access these choices.
>
> As another example of the inherent problems in this business,
> consider the elliptic integrals. TR1 specifies the usual
> first, second, and third kind functions, the way they
> appear in textbooks. GSL includes these, but prefers
> the Carlson forms. Carlson's book made it clear to me
> that his forms are the most logical and are the best
> for numerical implementation. Experts agree.
>
> The general point is that the idea of "elliptic integrals"
> is not just a couple of functions, it is really a family
> of functions, joined together by a single algorithmic
> idea, the arithmetic-geometric-mean. A good library
> should express this.
>
> I could go on for a while about this. But here is a
> simple summary of my feeling about the TR1 special
> functions:
>
>   functions from TR1 that are simple enough
>   that they could work as standard components
>   -------------------------------------------
>   beta function
>   exponential integral
>   riemann zeta
>   
>
>   functions that are doubtful as standard components
>   --------------------------------------------------
>   all the Bessel variants
>   Laguerre
>   Legendre
>   Hermite
>   elliptic integrals
>
>
>   functions that will almost certainly fail as standard components
>   ----------------------------------------------------------------
>   hypergeometric functions, confluent and otherwise
>   
I've reached the same conclusions basically.
The elliptic integrals don't seem to bad though If you use the 
underlying Carlson implementation.
The Carlson implementation seems almost universal from what I've seen.  
I would almost put them in the first group.
>
> Here is a final philosophical rant.
> It is easy to see why elementary functions should be standard
> components, regardless of the level of complexity in their
> implementation. Thankfully, they are simple enough. It is
> possible to argue that the gamma function should be a standard
> component, but I think the only reason this holds up is that
> we have the Lanczos algorithm. Without Lanczos, the gamma
> function might be some hairy beast, requiring trade-offs 
> that would complexify it beyond the realm of standard
> components. By the time we get to the confluent hypergeometric
> function, we are way out in a specialized problem domain,
> where trade-offs and details become key to a successful
> library implementation. Such functions have no place
> as standard components.
>
> Does anybody have use cases for things like confluent
> hypergeometric? Who needs these functions, why do they need
> them, and how do they expect to use them? 
>
> Sorry to be so negative. Maybe you can tell me why I'm crazy.
>
>
>   
The only functions I have not personally used or seen used are precisely 
the hypergeometric functions.  I think there is a long standing allure 
of "one function to rule them all".  If you *had* a stable efficient 
hypergeometric function, you could compute everything else with it.  
Plus the name sounds cool ;-).  I think you are right about the insanity 
of having the hypergeometric functions.

I think that my recommendation as far as C++ standards would be to drop 
the hypergeometric functions entirely - even from TR1.  I have mixed 
feelings about whether these functions should migrate from TR1 to the 
main standard.  In practical terms I think they will not make it 
precisely because the implementations are not really set in stone.  
Standards are supposed to *ratify* widely used practice - not to push an 
agenda.  Also, as has been alluded do in these standards discussions - 
if you implement these functions where do you stop?  What about Airy 
functions? Or all the functions that statisticians use?  People have 
noted that the choice of functions is physicist-centric.

I think implementations that are fairly useful can be provided for most 
of these functions.  I'm going to keep plugging on gcc.  I think it is 
worth exposing these if only to show the difficulties.  Maybe I won't 
kill myself on the hypergeometrics though!

I think ultimately the way to go in C++ (or maybe even C) would be to 
have dumb algorithms and smart numbers.  Basically one would crank sums 
with multi-precision numbers that kept track of errors or kept a fixed 
precision - speed be damned.  I think there are libraries that do this.
>> Concerning complex I swore that conforming C++ was supposed to store the 
>> real and imaginary parts in such a way that you could interact with 
>> C99.  I *think* you should be able to cast back and forth and have it 
>> work.  Also, a large part of this TR1 deals with syncing C99 with C++ 
>> (section 8).
>>     
>
>   
>> I thought there was a way you could grab the raw implementation and use 
>> it in C99 and conversely put a C99 _Complex in a constructor for C++ 
>> complex.
>> I'll dig around and see.
>>     
>
> As it does for Linas, this has bothered me for years. At this point
> I have no idea what the standards (or anybody else for that matter)
> can guarantee about compatibility between std::complex and C99 complex.
> As far as I could tell previously, there was no way to make it
> work reliably, although it probably works by default with gcc on
> most platforms. Please do dig around and let us know what you find.
>
> Thanks.
> --
> Gerard Jungman
>
>
>   
Thank you for weighing in on these issues.

Ed Smith-Rowland

Re: test release gsl-1.8.90.tar.gz

[Ed Smith-Rowland]

All,

I built and tested on x86_64 linux RHEL4 and everything went perfectly.

Ed Smith-Rowland