* Re: test release gsl-1.8.90.tar.gz @ 2007-02-17 15:14 Ed Smith-Rowland 0 siblings, 0 replies; 20+ messages in thread From: Ed Smith-Rowland @ 2007-02-17 15:14 UTC (permalink / raw) To: gsl-discuss All, I built and tested on x86_64 linux RHEL4 and everything went perfectly. Ed Smith-Rowland ^ permalink raw reply [flat|nested] 20+ messages in thread
* test release gsl-1.8.90.tar.gz @ 2007-02-15 12:51 Brian Gough 2007-02-15 23:24 ` Patrick Alken ` (5 more replies) 0 siblings, 6 replies; 20+ messages in thread From: Brian Gough @ 2007-02-15 12:51 UTC (permalink / raw) To: gsl-discuss 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-15 12:51 Brian Gough @ 2007-02-15 23:24 ` Patrick Alken 2007-02-16 8:24 ` Leopold Palomo Avellaneda 2007-02-16 21:16 ` Brian Gough 2007-02-16 5:03 ` Ed Smith-Rowland ` (4 subsequent siblings) 5 siblings, 2 replies; 20+ messages in thread From: Patrick Alken @ 2007-02-15 23:24 UTC (permalink / raw) To: gsl-discuss [-- 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-15 23:24 ` Patrick Alken @ 2007-02-16 8:24 ` Leopold Palomo Avellaneda 2007-02-16 14:30 ` Patrick Alken 2007-02-16 21:16 ` Brian Gough 1 sibling, 1 reply; 20+ messages in thread From: Leopold Palomo Avellaneda @ 2007-02-16 8:24 UTC (permalink / raw) To: gsl-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-16 8:24 ` Leopold Palomo Avellaneda @ 2007-02-16 14:30 ` Patrick Alken 2007-02-16 18:27 ` Leopold Palomo Avellaneda 0 siblings, 1 reply; 20+ messages in thread From: Patrick Alken @ 2007-02-16 14:30 UTC (permalink / raw) To: gsl-discuss 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-16 14:30 ` Patrick Alken @ 2007-02-16 18:27 ` Leopold Palomo Avellaneda 0 siblings, 0 replies; 20+ messages in thread From: Leopold Palomo Avellaneda @ 2007-02-16 18:27 UTC (permalink / raw) To: gsl-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-15 23:24 ` Patrick Alken 2007-02-16 8:24 ` Leopold Palomo Avellaneda @ 2007-02-16 21:16 ` Brian Gough 1 sibling, 0 replies; 20+ messages in thread From: Brian Gough @ 2007-02-16 21:16 UTC (permalink / raw) To: gsl-discuss 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-15 12:51 Brian Gough 2007-02-15 23:24 ` Patrick Alken @ 2007-02-16 5:03 ` Ed Smith-Rowland 2007-02-16 16:35 ` Linas Vepstas 2007-02-16 21:24 ` Brian Gough 2007-02-16 5:42 ` Yoshiki TSUNESADA ` (3 subsequent siblings) 5 siblings, 2 replies; 20+ messages in thread From: Ed Smith-Rowland @ 2007-02-16 5:03 UTC (permalink / raw) To: gsl-discuss [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-16 5:03 ` Ed Smith-Rowland @ 2007-02-16 16:35 ` Linas Vepstas 2007-02-17 15:08 ` Ed Smith-Rowland 2007-02-16 21:24 ` Brian Gough 1 sibling, 1 reply; 20+ messages in thread From: Linas Vepstas @ 2007-02-16 16:35 UTC (permalink / raw) To: Ed Smith-Rowland; +Cc: gsl-discuss 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-16 16:35 ` Linas Vepstas @ 2007-02-17 15:08 ` Ed Smith-Rowland 2007-02-20 23:20 ` Gerard Jungman 0 siblings, 1 reply; 20+ messages in thread From: Ed Smith-Rowland @ 2007-02-17 15:08 UTC (permalink / raw) To: Linas Vepstas; +Cc: gsl-discuss 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-17 15:08 ` Ed Smith-Rowland @ 2007-02-20 23:20 ` Gerard Jungman 2007-02-21 5:15 ` Ed Smith-Rowland 0 siblings, 1 reply; 20+ messages in thread From: Gerard Jungman @ 2007-02-20 23:20 UTC (permalink / raw) To: Ed Smith-Rowland; +Cc: Linas Vepstas, gsl-discuss 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-20 23:20 ` Gerard Jungman @ 2007-02-21 5:15 ` Ed Smith-Rowland 0 siblings, 0 replies; 20+ messages in thread From: Ed Smith-Rowland @ 2007-02-21 5:15 UTC (permalink / raw) To: Gerard Jungman; +Cc: Linas Vepstas, gsl-discuss 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-16 5:03 ` Ed Smith-Rowland 2007-02-16 16:35 ` Linas Vepstas @ 2007-02-16 21:24 ` Brian Gough 1 sibling, 0 replies; 20+ messages in thread From: Brian Gough @ 2007-02-16 21:24 UTC (permalink / raw) To: gsl-discuss 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/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-15 12:51 Brian Gough 2007-02-15 23:24 ` Patrick Alken 2007-02-16 5:03 ` Ed Smith-Rowland @ 2007-02-16 5:42 ` Yoshiki TSUNESADA 2007-02-16 8:09 ` Tim Fenn ` (2 subsequent siblings) 5 siblings, 0 replies; 20+ messages in thread From: Yoshiki TSUNESADA @ 2007-02-16 5:42 UTC (permalink / raw) To: Brian Gough; +Cc: gsl-discuss 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-15 12:51 Brian Gough ` (2 preceding siblings ...) 2007-02-16 5:42 ` Yoshiki TSUNESADA @ 2007-02-16 8:09 ` Tim Fenn 2007-02-16 21:25 ` Brian Gough 2007-02-16 8:20 ` Jari Häkkinen 2007-02-16 22:47 ` Dirk Eddelbuettel 5 siblings, 1 reply; 20+ messages in thread From: Tim Fenn @ 2007-02-16 8:09 UTC (permalink / raw) To: Brian Gough; +Cc: gsl-discuss 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-16 8:09 ` Tim Fenn @ 2007-02-16 21:25 ` Brian Gough 2007-02-20 9:14 ` Tim Fenn 0 siblings, 1 reply; 20+ messages in thread From: Brian Gough @ 2007-02-16 21:25 UTC (permalink / raw) To: gsl-discuss 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-16 21:25 ` Brian Gough @ 2007-02-20 9:14 ` Tim Fenn 2007-02-20 13:04 ` Brian Gough 0 siblings, 1 reply; 20+ messages in thread From: Tim Fenn @ 2007-02-20 9:14 UTC (permalink / raw) To: Brian Gough; +Cc: gsl-discuss 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 --------------------------------------------------------- ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-20 9:14 ` Tim Fenn @ 2007-02-20 13:04 ` Brian Gough 0 siblings, 0 replies; 20+ messages in thread From: Brian Gough @ 2007-02-20 13:04 UTC (permalink / raw) To: Tim Fenn; +Cc: gsl-discuss 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/ ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-15 12:51 Brian Gough ` (3 preceding siblings ...) 2007-02-16 8:09 ` Tim Fenn @ 2007-02-16 8:20 ` Jari Häkkinen 2007-02-16 22:47 ` Dirk Eddelbuettel 5 siblings, 0 replies; 20+ messages in thread From: Jari Häkkinen @ 2007-02-16 8:20 UTC (permalink / raw) To: gsl-discuss 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) > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: test release gsl-1.8.90.tar.gz 2007-02-15 12:51 Brian Gough ` (4 preceding siblings ...) 2007-02-16 8:20 ` Jari Häkkinen @ 2007-02-16 22:47 ` Dirk Eddelbuettel 5 siblings, 0 replies; 20+ messages in thread From: Dirk Eddelbuettel @ 2007-02-16 22:47 UTC (permalink / raw) To: Brian Gough; +Cc: gsl-discuss 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2007-02-21 5:15 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-02-17 15:14 test release gsl-1.8.90.tar.gz Ed Smith-Rowland -- strict thread matches above, loose matches on Subject: below -- 2007-02-15 12:51 Brian Gough 2007-02-15 23:24 ` Patrick Alken 2007-02-16 8:24 ` Leopold Palomo Avellaneda 2007-02-16 14:30 ` Patrick Alken 2007-02-16 18:27 ` Leopold Palomo Avellaneda 2007-02-16 21:16 ` Brian Gough 2007-02-16 5:03 ` Ed Smith-Rowland 2007-02-16 16:35 ` Linas Vepstas 2007-02-17 15:08 ` Ed Smith-Rowland 2007-02-20 23:20 ` Gerard Jungman 2007-02-21 5:15 ` Ed Smith-Rowland 2007-02-16 21:24 ` Brian Gough 2007-02-16 5:42 ` Yoshiki TSUNESADA 2007-02-16 8:09 ` Tim Fenn 2007-02-16 21:25 ` Brian Gough 2007-02-20 9:14 ` Tim Fenn 2007-02-20 13:04 ` Brian Gough 2007-02-16 8:20 ` Jari Häkkinen 2007-02-16 22:47 ` Dirk Eddelbuettel
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).