
Boost : 
From: Eric Ford (eford_at_[hidden])
Date: 20010909 20:21:38
> So I am as yet unconvinced at the importance of the the 'interface'
> beyond defining things as, for example,
>
> double function(double);
>
> The algorithms are the hard bit, I believe.
Obviously, algorithms are important and a whole field of study in
their own right. Let's not argue about which is more important. I
beleive there already exist a number of algorithms, libraries, and
numerical packages, but I often find it difficult to combine them in
the ways necessary for my science.
The reason I'd like to see a good interface is that then it would be
easier to combine diffent algorithms. For example, say I want to
calculate a 99.9% confidence interval for some statistic. I'd like to
be able to use a boot strap algorithm with the statistic I'm
interested in, that statistic might be calculated from a cumulative
from a distribution, that distribution could be the convolution of two
other distributions. I think a well designed interface should allow
me to combine two builtin distributions, a convolver, an integrator,
a boot strap algorithm, and a statistic calculator. Presently, I'm
not aware of any C/C++ package that allows those to be easily
combined. Often combining different packages is so difficult, it's
easier just to do it all myself. The only packages I know of that do
this are things like maple, mathematica, or matlab, and these
typically have major speed issues.
In the past, it's been practically inpossible to write a single good
math library. If it was to be fast, then everything had to be hard
coded. Yet, then it wasn't very flexible or useful. Allowing the
user to have options (how accurate? error checking? how to deal with
errors? etc) came at a speed price that made the library worthless to
many people. Templates offer the possibility of producing a single
mathematical library that is both very efficient and very versatile.
I see that as a big step forward.
There's a lot more than just float, double and long double. Error
checking, error handeling, and accuracey have already been identified
as things where users are likely to have different needs. I think the
speed/correctness trade off for error checking and handeling is
obvious. Like you said, often statistical functions aren't needed
very accurately. Templates provide a good means of allowing a single
library to address all possible combinations of these.
Please don't let me discourage you. If I were only interested in a
nontemplated set of mathematical functions, then I certainly wouldn't
want to spend much of my time trying to make it more general just
because someone else wanted that. Maybe you're interested in making a
good set of wellwritten common mathematical functions for doubles
only and a specific choice of error checking/handeling. If so, please
keep me informed of it's status. Assuming you produce good code and
give it a generous license, it could be very useful to those of us who
are interested in making a more general library. Then your code could
help quickly establish a reasonable collection of functions. If
you're interested in trying to make your code more easily generalized,
then you might consider helping us out by some of the following:
1. Document/comment code well
1a. Provide references to sources for nonobvious algorithms
1b. Document assumptions of algorithms (e.g. does it algorithm work
for integers, reals, negative values, complexes? does a have to be
less than 100? etc.)
1c. Document limitations (e.g. accuracey, degeneracies, etc.)
1d. Explicitly document differences between similar functions
2. Code with an eye to someone later generalizing things.
2a. Give constants meaningful names (e.g. maximum_error and
maximum_iterations for an iterative algorithm)
2b. Break up complicated mathematical functions into several smaller
functions with good names (e.g. double lngamma(double z) might be
implemented in terms of calc_ln_gamma_negative_z and
calc_gamma_positive_z)
Thanks,
E
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk