[boost] Re: Thoughts on Numeric Integration

From: Dan Mcleran (dan.mcleran_at_[hidden])
Date: 2002-10-24 10:48:09

"Daryle Walker" <dwalker07_at_[hidden]> wrote in message
news:54FFBEBC-E72A-11D6-98FC-0003939C8002_at_snet.net...
> For now, let's stick with functions that map one real number to another
> (so no complex numbers or vector mapping(s)).  A basic function design
> could be:
>
> template < typename ResultType, typename DomainType, typename RangeType
>  >
> ResultType
> integrate
> (
>      std::map<DomainType, RangeType>  m,
>      ResultType                       initial_condition = ResultType()
> );
>
> This is pure numerical integration without assuming any distribution
> pattern for the domain or range values (except that all the domain
> values are unique).
>
> That function can't work unless all the points are known in advance.
> If we build the graph as we go, we need something like:
>
> template < typename ResultType, typename DomainType, typename RangeType
>  >
> class integrator
> {
> public:
>      explicit  integrator( ResultType initial_condition = ResultType() );
>
>      void  update( DomainType x, RangeType y );
>
>      ResultType  current_result() const;
> };
>
> We should insist that updates keep new "x" values strictly increasing
> (or risk undefined behavior), so we don't have to keep an arbitrary
> history.
>
> Now for the variants:
>
> A. The domain values can be given be an STL iterator sequence; an
> initial value, step size, and final value or step count; a generator
> (C++) function/functor.
>
> B. The range values can be given in similar ways, or with a (C++)
> function/functor that takes processes the current domain value.  The
> latter option could be combined with hints about the (math) function's
> discontinuities or undefined regions.
>
> C. The domain and range values can be given in a combined STL iterator
> sequence of tuples.
>
> Note that specific techniques are not mentioned.  If there are several
> ways to do an integration (rectangular rule, trapezoidal rule, Simpon's
> Rule, etc.), we can provide similar (C++) functions or classes with the
> same signature, or policies could be used.  (I don't know too much
> about the "policy" philosophy with C++ programming techniques, could
> someone explain it to me privately?)
>
> Daryle
>

Daryle,

I didn't read your post until I had completed my last one. One of the
options I see going forward is to use an integration policy within an
integrator class. Feel free to join the discussion on 1D numerical
integration interface.

Regards,

Dan McLeran