solvers in Instruments - why nested classes rather than adapter+binder?

[Chris Kenyon-2]

Hi,

I have a question about use of solvers, e.g. in Instruments & Engines.  In classes such as CapFloor a nested class in the Instrument is used to provide a function to a solver by overloading the  () operator (see capfloor.hpp & capfloor.cpp).   However, the same result can be achieved by using an ordinary method (no overloading) together with a binder and an adapter (see 18.4.4 of C++ 3rd edition), plus a bit of boost, e.g.:

----------------------------------------
#include "boost/function.hpp"
#include <functional>

boost::function1<Real, Real> f;
f = std::bind1st( std::mem_fun( &className::methodName ),  &(*this) );
Brent solver;    
Real resultX = solver.solve(f, accuracy, guess, minX, maxX);
----------------------------------------

No changes are required in the solver code.  (Of course you need to set up methodName to return the difference between the targetValue and the value generated by the method call.)  This seems to avoid a lot of the overhead of creating a nested class at the cost of using a potentially obscure (but supported) piece of C++ generics, plus boost which is already used.

So why go with embedded classes?  What was the rational?

Very curiously,

CMK

p.s. another potentially cleaner alternative, local classes, is not supported by most compilers.

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

[Luigi Ballabio]

On Tue, 2007-03-20 at 10:49 -0700, Chris Kenyon wrote:
> I have a question about use of solvers, e.g. in Instruments & Engines.
> In classes such as CapFloor a nested class in the Instrument is used
> to provide a function to a solver by overloading the  () operator (see
> capfloor.hpp & capfloor.cpp).   However, the same result can be
> achieved by using an ordinary method (no overloading) together with a
> binder and an adapter [...]
>
> So why go with embedded classes?  What was the rational?

Historical reasons, I guess. In later versions of the library, the
solve() method was not template, and the function object to be passed
had to inherit from a base class. When we changed solve(), we didn't
bother changing the client code since it worked as it was.

Moreover, the inner class is not so bad. It encapsulates nicely a few
accessory object which otherwise should be kept as data members of the
CapFloor class itself. What we could do, however, is to avoid defining
it as an inner class. We could remove it from the header altogether and
define it in an anonymous namespace in the .cpp file. Did you spot any
other such class in the library?

Later,
        Luigi


----------------------------------------

I've finally learned what `upward compatible' means. It means we
get to keep all our old mistakes.
-- Dennie van Tassel



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