RE: [boost] Re: Math Functions

From: Paul A. Bristow (boost_at_[hidden])
Date: 2001-09-10 09:50:24

OK I can see that these things are also important, but I
don't want them to distract the mass of naive punters
(like me to some extent).

Perhaps we can try your ideas out on some fiarly simple,
but useful functions to see how they work out. 
The hart approximations for example.

I'll give this matter some thought when I get back from holiday 
early october.

Paul

PS  Is the FORTRAN ACM TOMS 715 by W Cody SPECFUN
a good list of the things needed to build the
staitistcs items I listed before?

> -----Original Message-----
> From: Eric Ford [mailto:eford_at_[hidden]]
> Sent: Monday, September 10, 2001 2:22 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: Math Functions
> 
> 
> > 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 built-in 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
> non-templated 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 well-written 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 non-obvious 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
> 
> 
> Info: http://www.boost.org  Unsubscribe: 
<mailto:boost-unsubscribe_at_[hidden]> 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/