Posted by
Luigi Ballabio on
Mar 29, 2007; 4:51pm
URL: http://quantlib.414.s1.nabble.com/Gauss-Kronrod-Implementation-tp9303p9304.html
On Mon, 2007-03-26 at 17:44 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> As you may have noticed I have coded a new implementation of Gauss
> Kronrod integration algorithm (the true one actually). It is coded in
> a slightly different way than other existing integration methods.
> First, I use boost::function to define the integrand, second, it is
> coded as a free (non member) function.
>
> I use boost::function to avoid templatization. This allow me to store
> the function definition in a cpp file and to provide the same
> flexibility in the integrand definition as with other methods. Do you
> agree with this approach ? or do you prefer the current
> implementation ? ( if you agree I can refactor the existing code
> quickly).
It's ok. As a matter of fact, we could modify the older integration
functions (the other Gauss-Kronrod, trapezoid, there might be others
which escape me now) so that they use boost::function. I'm not sure that
it's worth defining a typedef Integrand, though. For one thing, it's a
bit too generic. Leaving the raw boost::function type might be clearer.
> As for the second point, I have use a free function because I had no
> better idea. In fact I have the impression that current integration
> framework lacks a bit of consistency. I am tempted to provide an
> abstract base class and make all other inherit from it. Any
> thoughts ?
Having classes instead of free functions helps generic programming since
it gives all integral classes the same interface, namely,
Real operator()(boost::function<...> F, Real a, Real b) const;
whereas free functions have to be invoked with different numbers of
parameters. If your function were rewritten as a function object, you
would pass epsAbs and epsRel to its constructor, after which it would
have the same interface as the others (and therefore, could replace them
without modifying client code.)
I don't think you'll need an abstract base class. As the common
interface is operator(), client code needing an integrator can be
written as a template taking a generic F or as a non-template taking a
boost::function (although with a rather scary signature.)
Later,
Luigi
P.S. It should be gaussKronrodNonAdaptive (not "Adaptative")
----------------------------------------
Testing can never demonstrate the absence of errors in software, only
their presence.
-- W.E. Dijkstra
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev