Re: Templates

Posted by Ferdinando M. Ametrano-2 on Dec 20, 2000; 10:20am
URL: http://quantlib.414.s1.nabble.com/Re-Quantlib-dev-Linux-Port-tp1617p1624.html

Hi Bernd and all

>d) diminished transparence as only few understand templates well
>     enough.
>I am particularly concerned by d), as it is
>hard enough to find people who know how to write pricers, it is
>even harder to find those who also are well versed in C++ and
>templates. The use of templates  will raise the barriers of entry
>amoung students, academics and practitioners alike.
We've been through this discussion a couple of time in RiskMap.
We (finally?) agreed that QuantLib should be a 3 level project:
1) core base
2) pricing code
3) end user interface

I will give an (incomplete) example. Let's consider this first level statement:
FiniteDifferenceModel<CrankNicolson<TridiagonalOperator> >
myModel(theOperator);

[where theOperator is the tridiagonal discretization of BS equation]

It's scaring, I agree. The presence of that line of code in
bsmamericanoption.cpp is highly unsatisfactory. This is because the second
level is not ready yet.
The second level design is sketched in the same bsmamericanoption.cpp.
We will have a Model class implementing a common interface (rollBack(),
etc.) and somewhere in the first level there will be:
template <class Evolver>
class FiniteDifferenceModel : public Model {
}

typedef FiniteDifferenceModel<CrankNicolson<TridiagonalOperator> > BsmModel;

At this point, you can declare
Handle<Model> myModel(new BsmModel(gridSize));
[the safe equivalent of:
  Model* myModel = new BsmModel(gridSize);
]

Now - in the second level - the Model interface will remove all
implementation details (binomial, trinomial, finite difference) away and
will provide a common interface for any model. This will work for BDT, BK,
HW, etc. too, giving you the ability to write pricing code with pluggable
Model. Switching from one model to another will be very easy.
No template programming will be needed either.

The third level is the end user interface. Here I'm thinking about
scripting languages, MATLAB, Octave, Excel, applications that can be
written on QuantLib.
We will have to design an object interface for the environments supporting
objects and function interface for the others.
In the third level should be still possible to write pricing code (I'm
especially thinking of Python): of course this code will be inefficient,
but good enough for prototyping or not-demanding application.

ciao -- Nando