From: Martin Weiser (weiser_at_[hidden])
Date: 2002-11-04 04:22:02
On Sonntag, 3. November 2002 06:28, Daryle Walker wrote:
> On Friday, November 1, 2002, at 10:34 AM, Martin Weiser wrote:
> > template <class InIter>
> > FixedIntegrator<InIter>
> > integrate(InIter first, InIter last, double dx);
> > and FixedIntegrator is an option-setting integration class similar to
> > the
> > one designed for RAI, providing an implicit conversion to
> > typename std::iterator_traits<InIter>::value_type
> > What do you think? Do we need to provide integration points for
> > non-equidistant data as well? Is this case common enough?
> That interface could work for equidistant data. Am I right that the
> input iterators return only the y-values?
Yes, although a similar interface with the iterators returning pairs of
(x,f(x)) would be possible as well. However, integrating over irregularly
distributed data is either more expensive or less efficient than
equidistantly spaced data (well, that boils down to exactly the same
effect in both cases;)
> I mentioned another interface in my posts, one that accepts one point
> at a time and updates the integration, when you can't set up a point
> list in advance.
For me, that looks much more like a special case of integrating ordinary
differential equations. I think it should be handled there.
> We could do the non-equidistant data case. It is the most general
> case, the other cases are just specializations. In fact, an adaptive
> algorithm can call the general case after it determines what points to
Hm, that would be a surprise for me. In general, adaptive selection of
evaluation points, evaluation of the function at these points, and
approximating the integral are all closely entangled in adaptive
integration algorithms. Thus, a separation in (select points, evaluate)
and (integrate) would be quite useless. Correct me if I'm wrong.
-- Dr. Martin Weiser Zuse Institute Berlin weiser_at_[hidden] Scientific Computing http://www.zib.de/weiser Numerical Analysis and Modelling
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk