$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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