Boost logo

Boost :

From: Martin Weiser (weiser_at_[hidden])
Date: 2002-11-08 03:52:47


Hi Dan,

just a few comments and questions to your modifications:

On Montag, 4. November 2002 16:50, Dan Mcleran wrote:
> I've modified my code by incorporating some of yours and making some
> changes. There are obviously plenty of details yet to be done. What
> I've got now allows the user to:
>
> * specify argument and return type.

I can understand that there may be the desire to use a different return
type (say, interval instead of double), which would be used for
integration (say, with computing rounding error bounds). I have more
difficulties to come up with an example where one would like to change
the argument type, but that can be attributed to my limited imagination.

However, your _integrate interface function requires the functor to be a
template of two parameters (argument and return type), and that seems to
be a very restrictive requirement. The gain seems to be comparatively
low, since the difference between

template <class arg, class ret,
           template<class arg,class ret> class Functor,...> ...
_integrate(...)

_integrate<double,double,OneOver,...>(...)

and the allegedly less flexible

template <class Functor, ...>
_integrate(...)

_integrate<OneOver<double,double> >(...)

is really small. Am I overlooking something?

> * specify which Functor to integrate over

Ok, this seems to be the same for both our interfaces.

> * specify which method of integration to use

The difference here is that in your version the template parameter is
given explicitly to _integrate(), whereas in my version this is selected
via a template method call. While I think the template method is quite
elegant and fits nicely with the general option setting syntax, you're
completely right in pointing out that gcc 2.95 chokes on this.

So I think it would be possible to design a gcc 2.95 workaround for the
integration formula setting. Of course, this workaround could simply be
declared standard - introducing a slight internal inconsistence in the
interface, but consistent behavior across different compilers.

Don't know anything about Borland.

> I've included an implementation of Richardsons extrapolation and the
> Romberg rule. I've used this web page as a reference:
> http://www2.egr.uh.edu/~rbarton/Classes/ECE2331/Files.pdf/Notes/Notes_2
>-11-0 2.pdf
>
> The algortihm builds a Romberg table until the relative tolerance is
> met.

A nice step ahead. Once the interface is more or less fixed, the run for
the best implementation is open...

Yours,
Martin

-- 
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