Gauss Kronrod Implementation
Locked
Gauss Kronrod Implementation
 
|
Hi all,
Sorry to annoy you again with a some new questions, I hope to make myself clear enough this time ;-) 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). 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 ?
François
PS: What about using a forum dedicated to this kind of discussions ?
------------------------------------------------------------------------- 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 |
Re: Gauss Kronrod Implementation
|
|
Hi François
I was the one who added the Gauss-Kronrod algorithm to QuantLib years ago. But I'm not actively developing on QuantLib now, so I will leave it up to the active developers to decide which coding style is better. Was is the advantage of the new algorithm? Is it faster? More precise? Good to see contributions coming in! Best regards, Niels 2007/3/26, DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI <
[hidden email]>:
------------------------------------------------------------------------- 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 |
Re: Gauss Kronrod Implementation
|
|
In reply to this post by DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI
Hi Niels,
The version I have implemented uses an increasing number of evaluation of the integrand until it reaches the required precision. The key point is that it reuses all the values computed (with different weights each time). It uses up to 87 points; meaning that it is less robust than your adaptative algorithm which can use as many points as required. In particular, the integrand should be smooth enough otherwise we have to make a change of variable. Good to see that you keep an eye on what’s going on … Best regards, François
-----Original
Message-----
Hi
François 2007/3/26, DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI < [hidden email]>: Hi all,
Sorry to annoy you again with a some new questions, I hope to make myself clear enough this time ;-) 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). 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 ?
François
PS: What about using a forum dedicated to this kind of discussions ?
------------------------------------------------------------------------- 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 |
Re: Gauss Kronrod Implementation
|
|
In reply to this post by DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI
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 |
| Free forum by Nabble | Edit this page |