
Boost : 
From: Dan Mcleran (dan.mcleran_at_[hidden])
Date: 20021024 10:48:09
"Daryle Walker" <dwalker07_at_[hidden]> wrote in message
news:54FFBEBCE72A11D698FC0003939C8002_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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk