
Boost : 
From: Dan Mcleran (dan.mcleran_at_[hidden])
Date: 20021024 10:39:02
1D Numerical Integration
All,
I have replied to my own post to start a discussion on the interface for a
1D numerical integration library. It seems that most everyone agrees that
separation of the interface for 1D, 2D, etc. is the right thing to do. I
also think everyone agrees that 1D numerical integration is straightforward
and could be part of boost.
Here are what I would suggest to be the highlevel requirements for
whichever direction we go for 1D numerical integration:
1. They must be able to integrate a userdefined function from point a to
point b in increments of deltax.
2. They must be able to integrate a set of results, i.e. results of f(x),
from point a to point b, given that the deltax can either be provided by the
user or it is implied that the deltax can be calculated by 1/(number of data
points  1).
As I see it, there are many ways to do this and I've tried to outline what I
see as the viable ways to go:
STLstyle algorithm(s):
We could have an algorithm for each type of numerical integration (I
have omitted parameters to simplify the discussion)
area = trapezoidal_integral();
area = simpsons_integral();
area = romberg_integral();
etc.
We could also have a generic algorithm where the integration routine
could be a template parameter (maybe a combination of algorithms
and functors). I have added params here for clarity. The example
below would be an algoritm that takes begin and end points, deltax, the
function to integrate, and the integration method.
area = integrate(a,b,deltax,Function,TrapezoidalIntegrator);
Functors
We could have numerous function objects:
std::for_each(begin,end,TrapezoidalIntegral());
std::for_each(begin,end,SimpsonsIntegral());
Firstclass Object(s)
Or we could have a class that could take a template parameter for which
method to use:
Integrator<TrapezoidalRule> i;
area = i.integrate();
My vote would be a collection of STLstyle algorithms. I think these are the
most straightforward and very selfdocumenting.
Other ideas for alternative interfaces would be welcome.
Regards,
Dan McLeran
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk