4 We are looking for volunteers to do the following tasks.
5 Consult the TODO files in each directory first for specific
8 * 1st-line support on the mailing lists (e.g. checking that bugs are
9 reproducible, and that all relevant information is supplied)
11 * Modified Ei(x) function (see specfunc/TODO)
13 * Quasi-random number distributions
15 * ODE algorithms from RKSUITE
17 * Incomplete Fermi-Dirac functions
19 * General Legendre functions
21 * Spheroidal wave functions
23 * Weierstrass elliptic functions
25 * Complex Bessel Functions
27 * Additional volunteers with access to a good library to get copies of
28 papers for other developers.
30 * Estimates of condition numbers for linear solvers
32 * Sine and Cosine Transforms from FFTPACK (Alok Singhal <as8ca@virginia.edu>)
34 * Cubature, e.g as provided by Cubpack. (Gert Van den Eynde
35 <gvdeynde@sckcen.be> ?)
37 * Mathieu functions (Lowell Johnson <ldj00@sio.midco.net>)
39 * Fresnel Integrals ("Juergen J. Zach" <jjzach@pacific.mps.ohio-state.edu>)
41 * Cumulative Distribution functions for discrete random distributions
45 * Remove use of long double internally, e.g. as an accumulator in
46 loops. It introduces variation between platforms which is undesirable.
47 It should be replaced with a preprocessor variable ACC_DOUBLE so
48 that the user can compile the library with the old long double
51 * Use BLAS internally as much as possible, to take advantage of
52 speed improvements on large-scale systems. There may be some
53 instances where a simple for() loop is preferred since there's a
54 function-call overhead in calling BLAS routines.
56 * More tests. We should (at least) have a test for every error
57 condition. Use GCOV to improve coverage.
59 * Annotate the header files with GAMS classifications. See if they
60 can be included in the GAMs website.
62 * Make the return value EINVAL vs EDOM consistent for invalid
63 parameters. EDOM means a domain error (i.e. float or mathematically
64 undefined), EINVAL means invalid (i.e. zero length)
66 * Change return 0 to return GSL_SUCCESS, and return -1 to GSL_FAILURE
67 throughout, where appropriate. Similarly change any if(...) checks of
68 return values to use == GSL_SUCCESS, if they are checking for zero.
69 N.B. want to be careful about accidentally omitting error conditions
70 if using something like == GSL_FAILURE when function returns a
73 * Make sure that all #defines are fully wrapped in ()'s, especially
74 the outermost layer which may have been missed. Everything should be
75 of the form #define foo(x) (....) so there is no possibility of bad
76 parsing. Need a perl script to check this!
78 * Clean up the ordering of lines in the Makefile.am's so that they are
79 all consistent. At the moment the lines are in any order.
81 * Eliminate use of volatile where it has been used to force rounding
82 (integration/). It is better to write the code to avoid dependence on
85 * Constant objects (like gsl_roots_fsolver_brent) ought to have
86 constant pointers (const gsl_roots_fsolver_type * const
87 gsl_roots_fsolver_brent)
89 * PyGSL -- python bindings for GSL, see http://pygsl.sf.net/
95 Kernel Density Estimation
96 Shampine Polynomial Regression
97 Bootstrapping, Jacknife
98 Descriptive: Range, Trimmed Mean, Winsorized Mean, Moments
99 Harmonic mean, RMS, Durbin-Watson, AR1 independence
100 Autocorr, Autocorr_z, Cramer vos Mises, Anderson-Darling
101 Spearman-rho, Kendall-tau, EDF_D_both EDF_D_plus,
102 EDF_D_minus, EDF_D, EDF_kuiper_V, pooled mean
104 Tests: kolmogorov_smirnov
105 Moving average, Exponential moving average
106 wilcoxon_statistic, wilcoxon_noties_cdf, wilcoxon_general_cdf
107 Cochran Q test, KruskalWallis, McNemar, spearman_Rocc
110 Wishlist or vague ideas
111 =======================
113 * An example chapter on how to link GSL code with GNU Guile, and Python
115 We could also provide g-wrap wrappers for guile, or swig.i files and
116 swig demos so that swig can be run more easily.
118 * Provide an interface to LAPACK, as for BLAS? Clarify the license
119 for LAPACK first, their web page is vague on what the license terms
120 are. Some parts of LAPACK are included in octave so maybe the Octave
121 maintainers will know more.
123 * Public domain or free texts which could be distributed with GSL:
125 Abramowitz and Stegun, "Handbook of Mathematical Functions" appears to
128 SEPT/02: See online images at http://members.fortunecity.com/aands/
130 Devroye's book on Random Variates (1st ed) is/was in the public
134 * Investigate complex support in GCC: Operations like sin(z) silently
135 convert argument to double, losing the imaginary part. This is
136 mentioned in CEPHES documentation in 1998 with a patch to generate a
137 warning. What happened? (Does it now work with gcc-3.0?)
139 * Go through the matrix and vector functions systematically and decide
140 what should be provided outside of BLAS.
142 * Standardize function names, in particular VERB vs NOUN (e.g. _invert
143 vs _inverse). Also adopt a convection for functions which can operate
144 in place vs use of workspace (e.g linalg_solve functions).
146 * Change from gsl-ref.texi to gsl.texi since it is the main file?
147 Also, put under dir section "Math" (which seems to be the appropriate
148 one for Debian, as Octave, Gnuplot etc are in that)
150 * Remove error stream stuff?? It is hardly used.
152 * Extend histogram routines as described in recent discussion
154 * Check that there are no conflicts when linking with Lapack. CBLAS, ATLAS
156 * Make a sorted datatype for the median and quantile functions so that
157 the user can be prevented from passing unsorted data, which is not
160 * Optimization/error for dest == src as appropriate
162 * Provide a run-time expression evaluator for interactive programs
163 where the user can provide formulas as strings. Keith Briggs
164 recommended formulc2.22 which he had found useful in several projects.
165 http://www.cs.brandeis.edu/~hhelf/formu/formulc.html. It is LGPL.
166 Alternatively, the source code for GDB contains yacc grammars and
167 evaluators for expressions in various languages, so that would be
168 another way to go. It would have the advantage of following the
169 language standards. If I was going to write something from scratch I
170 would think about using that as a base, as the full set of operators
171 are already included with the correct precedence rules. Being able to
172 evaluate C and Fortran expressions could be useful.
174 * We should have an index mapping type object which handles elements
175 of size_t for vectors and matrices, or at least vectors and matrices
176 of size_t in addition to long, int, etc.
178 * Fix up the workspace_alloc functions so they have consistent names