RE: Quantlib design

Posted by Henaff, Patrick on Dec 31, 2000; 11:56pm
URL: http://quantlib.414.s1.nabble.com/Quantlib-design-tp1657p1667.html

First of all, apologies for perharps starting a thread in the wrong
direction. When I mentioned Qt, I didn't have a graphical interface in mind,
but was thinking of Qt as a foundation class library, to provide a de-facto
standard for low-level constructs (Lists, Dictionaries, date representation,
etc). Clearly, other libraries could fullfil the same role.

Several members suggested that a spreadsheet interface is needed, and I
fully agree. It's the basic tool on a trading floor.
In any case, I would not think of a C++ graphical interface, but use Python,
Tcl, etc.

Integration with matlab is also mentioned. I've just spent the past couple
of years deploying matlab-based tools on a trading floor (C dlls, matlab
wrapper and front end). In a nutshell, deployment is a nightmare, because of
interactions between the local desktop environment, the dlls, and matlab.
Matlab graphics are nice, but the price to pay is too high. If this was to
be done again, I would write the front end in Python, or as Java applets.

Regarding design, as mentioned earlier, we mostly used the ideas found in
Fowler's. The most important aspects, in our view, are as follows:
* The model for phenomenon, measurements and quantities. We model all
market data and all computed values as measurement of a particular
phenomenon on a financial instrument. A measurement yields a quantity, which
is an abstract type for all sorts of representations of market data (e.g.
forward curves, time series, volatility surfaces, etc).
* Collections of market data are grouped into scenarios. This provides
a general framework for implementing simulations, and for easily switching
from a front office data set to a risk department data set, for example.
* Portfolios defined by filtering rules on a set of trades, as opposed
to defining a fixed hierarchy of book/portfolio/trade.

I agree with several participants that at this stage, defining the design of
the object model is the most important step. In our experience, this was by
far the hardest portion of the project. In contrast, once this was done,
adding new valuation model became almost trivial. I would suggest to develop
a proof of principle of the object model that illustrates the following
points:
* The hierarchy of instruments, which should include tradable assets
as well as indices, etc.
* The relationships between a derivative and its underlying asset.
* The independence between valuation models and asset definition. For
example, illustrate how a bond option may be valuated using a simple BS
model, or a one-factor BDT model.
* The model for defining cash flow schedules

        A sound design would make QuantLib very attractive to developpers,
and would set it apart from commercial pricing libraries. In particular, a
design that would make it easy to investigate the effect of alternate
valuation models. This would turn QuantLib into a financial lab that should
be attractive to researchers and graduate students, who, in turn would push
the acceptance of QuantLib into the corporate world. In fact I would focus
on this point as the competitive advantage of QuantLib over commercial
libraries.