Quantlib design

[Henaff, Patrick]

I read with great interest the documentation for quantlib. We have recently
completed a rather large project in the same vein, but dealing with
commodities rather than fixed-income. The basic design issues are identical,
however. Based on this experience, may I venture a few suggestions to the
designers:

It would be useful to publish a white paper describing the object model for
trades, instruments, market data and models. In our own project, we
benefited from Martin Fowler's book, "Analysis Patterns". In particular
chapters 3, 9, 10 and 11 provide an extremely well thought out blueprint for
a project of this nature.

I may have misunderstood the documentation, but as I read it, I see, for
example, "London" to be a subclass of "Calendar". In our project, this would
be an instance of Calendar, not a subclass. Same remark for day counts,
currencies. We have made extensive use of the design patterns described by
the "gang of 4". In particular, we systematically use the factory pattern to
instantiate objects. Thus, we have a currencyFactory, calendarFactory, etc.

Early traffic on the mailing list involves discussions on basic programming
constructs. It might be helpful to build quantlib on top of a general
purpose class library (e.g. Qt), which would provide a de-facto standard for
many low-level idioms.

Best wishes.

[Ferdinando M. Ametrano-2]

Hi all

>It would be useful to publish a white paper describing the object model for
>trades, instruments, market data and models. In our own project, we
>benefited from Martin Fowler's book, "Analysis Patterns". In particular
>chapters 3, 9, 10 and 11 provide an extremely well thought out blueprint for
>a project of this nature.
Thank you for the suggestion. I'm currently on vacation with my family so I
don't have Fowler's book handy (I haven't read it yet since I got it few
moths ago along with a couple dozen more titles).
Luigi and Marco are at work so I'm sure they won't resist reading those
chapters asap ;-)

In the meantime Patrick if you want to elaborate I would appreciate.

>I may have misunderstood the documentation, but as I read it, I see, for
>example, "London" to be a subclass of "Calendar". In our project, this would
>be an instance of Calendar, not a subclass. Same remark for day counts,
>currencies. We have made extensive use of the design patterns described by
>the "gang of 4". In particular, we systematically use the factory pattern to
>instantiate objects. Thus, we have a currencyFactory, calendarFactory, etc.
This is a good point. As you probably noticed in QuantLib there's a folder
dedicated to patterns. As of now it contains observable only, but it can grow!

>Early traffic on the mailing list involves discussions on basic programming
>constructs. It might be helpful to build quantlib on top of a general
>purpose class library (e.g. Qt), which would provide a de-facto standard for
>many low-level idioms.
Qt is a good GUI software toolkit. I am not an expert in this area but I
would probably also consider wxWindows.
A graphical interface to QuantLib would be nice so if someone can provide
it that's good.

Anyway for the time being I would like the project to be focused on the
library itself. I'm pretty sure the API will change many times, so it's
early to think about application, as much as it's early to think about HJM
models.
QuantLib needs way better foundations to build upon in a consistent way

ciao -- Nando

[Luigi Ballabio-3]

At 11:07 AM 12/27/00 +0100, Ferdinando Ametrano wrote:

>>I may have misunderstood the documentation, but as I read it, I see, for
>>example, "London" to be a subclass of "Calendar". In our project, this would
>>be an instance of Calendar, not a subclass. Same remark for day counts,
>>currencies. We have made extensive use of the design patterns described by
>>the "gang of 4". In particular, we systematically use the factory pattern to
>>instantiate objects. Thus, we have a currencyFactory, calendarFactory, etc.
>This is a good point. As you probably noticed in QuantLib there's a folder
>dedicated to patterns. As of now it contains observable only, but it can grow!

First of all: Nando, shut down that laptop! You're in vacation, for
goodness sake! :)

As for the Calendar thing: indeed London and the other calendars are
Calendar subclasses. This is due to the fact that isBusinessDay() is more
easily implemented as a virtual function. Right now I can't think of
another implementation, apart from adding to Calendar a vector of holidays
to search dates in and having the factory fill it with the right holidays
upon construction. However, this would have a few disadvantages, namely,
a) the calendar instances would be heavier to build and/or pass around. Of
course we could always define a few global instances to refer to.
b) the array would contain holidays up to a certain year, not general rules
for building them.
This actually brings to my mind another implementation in which Calendar
contains a vector of rules. But a structure holding a generic rule (which
could be either "December 25th" or "the first Monday of May" or "January
1st, possibly moved to Monday if it is a Saturday or Sunday") seems to me
to be somehow more complicated than the current implementation.

How did you manage the thing in your implementation?

Furthermore, the implementation of calendars as subclasses does not prevent
using a factory: the latter would simply return a Handle<Calendar> (i.e.,
our smart pointer to the base class) initialized with a pointer to an
instance of the right subclass.

Bye for now,
                 Luigi

[Peter Schmitteckert-2]

Salut,

On Mit, 27 Dez 2000, Ferdinando Ametrano wrote:
[...]
>Qt is a good GUI software toolkit. I am not an expert in this area but I
>would probably also consider wxWindows.
>A graphical interface to QuantLib would be nice so if someone can provide
>it that's good.

Well, which feature should a first KDE2/QT KQuantLib application have?

>
>Anyway for the time being I would like the project to be focused on the
>library itself. I'm pretty sure the API will change many times, so it's
>early to think about application, as much as it's early to think about HJM
>models.
I was already thinking about starting a KQuantLib application, but I resisted
because of the reasons you mentioned above.

>QuantLib needs way better
>foundations to build upon in a consistent way.
Note that a graphical interface may increase the number of users (~ number of
alpha/beta tester),

Best wishes,
Peter

________________________________________
Dr. Peter Schmitteckert / IT-Consulting
s-mail: Fridolinstr. 19, 68753 Waghäusel
Web: http://www.schmitteckert.com
e-mail: [hidden email]
Tel.: [phone]

[Bernd Johannes Wuebben-2]

> >Qt is a good GUI software toolkit. I am not an expert in this area but I
> >would probably also consider wxWindows.
> >A graphical interface to QuantLib would be nice so if someone can provide
> >it that's good.
>
> Well, which feature should a first KDE2/QT KQuantLib application have?

Where would an application build on the KDE libraries add value at this
point? We have python for scripting (other such as perl, java etc can be
added over time leveraging swig) As far as visual working with the data
is concerned I prefer spread sheets (Excel to be precise and I will
contribute the sceleton of an excel interface soon). Interfaces to matlab,
octave, R, etc  are essentially trivial to write which will address
another area of use. As far as hardcoded GUI applications are concerned I
can only see a use in the back-office sector, which is light years way
from where we are now and frankly just looking at our sources in their
current embryonic state I consider it evident that we have much more
important  things to worry about at this point that the back office.

> Note that a graphical interface may increase the number of users (~ number
of
> alpha/beta tester),

No, not gui interfaces, but rather spread sheet interfaces (Excel, Applix,
Star office, Gnumeric, Kspread). GUI interfaces in the classical sense of
the word, are IMHO virtually useless with the exception of certain
repetetive low level  back-office functions. Spread sheets are the tools
used on the floor and without them we are nothing (as far as the reail
world is concerned) and with them we have an ideal tool to play/test/
document functionality.

The creation of spreadsheet interfaces may require some brainstorming,
as they need ot be more or less automatically generated from the
sources. In the sources proper interfaces/objects/functions/pricers will
have to be defined through special syntax in the sources from which
spreadsheet interface sources will have to be generated automatically,
otherwise maintenance of the spread sheet bindings may become a headache.

Bernd

[Peter Schmitteckert-2]

Dear Bernd,

On Mit, 27 Dez 2000, you wrote:
[...]

>Where would an application build on the KDE libraries add value at this
>point? We have python for scripting (other such as perl, java etc can be
>added over time leveraging swig) As far as visual working with the data
>is concerned I prefer spread sheets (Excel to be precise and I will
>contribute the sceleton of an excel interface soon). Interfaces to matlab,
>octave, R, etc  are essentially trivial to write which will address
>another area of use. As far as hardcoded GUI applications are concerned I
>can only see a use in the back-office sector, which is light years way
>from where we are now and frankly just looking at our sources in their
>current embryonic state I consider it evident that we have much more
>important  things to worry about at this point that the back office.

I agree, that's why I asked which functionality a KQuantLib could provide.
To be specific, which benefits it could provide.

>No, not gui interfaces, but rather spread sheet interfaces (Excel, Applix,
>Star office, Gnumeric, Kspread). GUI interfaces in the classical sense of
>the word, are IMHO virtually useless with the exception of certain
>repetetive low level  back-office functions. Spread sheets are the tools
>used on the floor and without them we are nothing (as far as the reail
>world is concerned) and with them we have an ideal tool to play/test/
>document functionality.
Again, I agree. I won't waste my time in writing  a spread like application.
I have to excuse that I'm not familiar with financial analysis. Therefore I
wonder if there are problems beyond spread applications. And that's why
I'm resisting of getting too deeply involved in QuantLib at the moment, since
I want to do my homework in financial analysis first.
(Note that antiquated programmers like me even prefer awk over spread sheets,
and TeX over Word, and still use xterms and console applications).

Best wishes,
Peter

[Marco Marchioro-2]

Dear All,
         I agree with Bernd that the time is not ripe for an hard-coded
KQuantLib
and that the spreadsheet interface is by far the most useful at the moment.
I am also very interested in an Excel porting, therefore let me know when
I will be able to use the QuantLib basic functionalities on my spreadsheet

have a nice ending and the happiest new year (century, millennium),

                 Marco

At 12:20 00/12/28 +0100, Peter Schmitteckert wrote:

>Dear Bernd,
>
>On Mit, 27 Dez 2000, you wrote:
>[...]
> >Where would an application build on the KDE libraries add value at this
> >point? We have python for scripting (other such as perl, java etc can be
> >added over time leveraging swig) As far as visual working with the data
> >is concerned I prefer spread sheets (Excel to be precise and I will
> >contribute the sceleton of an excel interface soon). Interfaces to matlab,
> >octave, R, etc  are essentially trivial to write which will address
> >another area of use. As far as hardcoded GUI applications are concerned I
> >can only see a use in the back-office sector, which is light years way
> >from where we are now and frankly just looking at our sources in their
> >current embryonic state I consider it evident that we have much more
> >important  things to worry about at this point that the back office.
>I agree, that's why I asked which functionality a KQuantLib could provide.
>To be specific, which benefits it could provide.
>
> >No, not gui interfaces, but rather spread sheet interfaces (Excel, Applix,
> >Star office, Gnumeric, Kspread). GUI interfaces in the classical sense of
> >the word, are IMHO virtually useless with the exception of certain
> >repetetive low level  back-office functions. Spread sheets are the tools
> >used on the floor and without them we are nothing (as far as the reail
> >world is concerned) and with them we have an ideal tool to play/test/
> >document functionality.
>Again, I agree. I won't waste my time in writing  a spread like application.
>I have to excuse that I'm not familiar with financial analysis. Therefore I
>wonder if there are problems beyond spread applications. And that's why
>I'm resisting of getting too deeply involved in QuantLib at the moment, since
>I want to do my homework in financial analysis first.
>(Note that antiquated programmers like me even prefer awk over spread sheets,
>and TeX over Word, and still use xterms and console applications).
>
>Best wishes,
>Peter
>
>_______________________________________________
>Quantlib-users mailing list
>[hidden email]
>http://lists.sourceforge.net/mailman/listinfo/quantlib-users

[Henaff, Patrick]

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.

[Mark Higgins]

> Regarding design, as mentioned earlier, we mostly used the
> ideas found in Fowler's.

Is Quantlib going to be a full risk management system, or is the
goal to be a standard library of calculation routines that any
risk management system could use?

My impression from the project description was the latter, but
let me know if I'm wrong.

If you're interested, I've also started an open source risk
management system, called the Finicky Financial Trading System
(http://ffts.sourceforge.net). It's still very much in
development, and I'd be very much interested in hearing design
ideas.

Quantlib is interesting to me as a source of pricing functions,
so I wouldn't have to reinvent the wheel for Black-Scholes
pricing, stochastic vol models, etc. Or at least, I could
write some of those routines and make them available in Quantlib

for others to use and improve on.



=====
-------------------------------------------------------
Mark Higgins, [hidden email]
http://www.molala.net

Opinions expressed herein do not reflect my own views;
I haven't had free will since last year when aliens ate
my brain.

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

[Ferdinando M. Ametrano-2]

Hi all

Mark wrote:
 > Is Quantlib going to be a full risk management system, or is the
 > goal to be a standard library of calculation routines that any
 > risk management system could use?
The latter.
I do think systems and GUIs based on QuantLib can be interesting (I actually
hope they will be the result of the QuantLib project): just don't expect
such projects to be merged into QuantLib development.
Before we reach that point we need a way better and more stable library,
and I don't think we'll get there in the near future.
Excel/Matlab/Octave/Python etc. are the suggested way to use QuantLib (see
also http://quantlib.sourceforge.net/goals.html)

 > If you're interested, I've also started an open source risk
 > management system, called the Finicky Financial Trading System
 > (http://ffts.sourceforge.net).
 > Quantlib is interesting to me as a source of pricing functions,
 > so I wouldn't have to reinvent the wheel for Black-Scholes
 > pricing, stochastic vol models, etc. Or at least, I could
 > write some of those routines and make them available in Quantlib
 > for others to use and improve on.
Just go ahead, that's why I started the project!

I've took a quick look at your project to see if/how we can merge.
[BTW what "Finicky" does mean?]

As a preamble I have to say that the GPL licence you adopted does not allow
QuantLib to borrow code from FFTS, unless you (the copyright holder) submit
your contributions to our licence. The reverse is possible with no problem.
[If anyone wants more details on the licence issue please check
http://quantlib.sourceforge.net/license.html]
Your mileage might vary, anyway I agree that GPL is a good choice for an
application. Since QuantLib is a library I choose a more "liberal" XFree-86
style licence that allows software company to use QuantLib in their
projects, whatever the licence they adopt. I might reconsider this, but not
in the near future and not without 100% consensus of all QuantLib
developers and the majority of QuantLib users.
In any case I ask not to start a licence thread here, not for the time
being please.

I select few issues I've found of immediate interest.
If you agree I hope you will consider reworking FFTS to link to QuantLib,
merging into QuantLib additional features you have and we miss. This can be
a gradual viable approach, that preserve our library nature and your
application nature.


a) folder FFTS\analitics
a1) BSOption: I noticed that we have an approach more object oriented, FFTS
has many function here.
This is not dramatic, especially since we'll work to produce Excel
extension, so a well designed function list is on our way.
You just need to wrap our class methods into your existing function
a2) AmericanOption: the same as above. You may need some tuning to
calibrate our finite difference approach to fit your speed/accuracy
constraints. Anyway this could be better than your binomial tree approach.
a3) BSOneTouch: we don't have one-touch barrier yet just because we're
lazy. It should be an easy task in the current framework.
What is important here is that we want to separate Model classes (trees,
finite difference) from pricing code (american, barrier, etc.)
I need to clarify our proposal for a Model class asap, but this will take
some time. Then I hope it will be clear how I would like FiniteDifference
and trees to share the same interface. This is why I skip FFTS\tree and
FFTS\PricingTree right now.
a4) instead of "int CallOrPut" we prefer enumerations. We have Straddle also.
a5) RandomLCG (Applied Cryptography random generator) and RandomGauss can
easily be added to our "Random Number" framework. What is the license for
Applied Cryptography?
a5) RootFinding: we already have Newton-Raphson and Brent. You may look at
our 1Dsolver interface that is shared by all our 1dimensional solvers
a6) ExtraMath.cpp and .h: we already have NormalDistribution and
CumulativeNormalDistribution functions. We miss the inversion of the
cumulative function (that is your InvCNormDist function). We can add this
(btw is it from the Abramowitz too?)
a7) interpolation: we need a more general object-oriented interpolation
tool. We sketched something at RiskMap but it's not finished yet. QuantLib
has a function newcubicspline for the time being, the non-sense name tells
the whole story.
Once the tool is ready you can use it in your VolFunctions

b) folder FFTS\string
format utilities can merge into our dataformatters.cpp and .h

c) folder FFTS\types
c1) date class: we miss some date parsing methods - even though we wonder
whether they belong to an external code layer rather than to the library.
However, we can easily merge here smoothing our little differences.
c2) matrix class. We at RiskMap have a similar class that we have not
contributed yet to QuantLib since it needs some work
c3) why you need a FractionalValue? (just wondering)
c4) class GenericCurve. Once again at RiskMap we have a similar class we're
unhappy with. The requirements here is that we plan to have both "discrete"
knot curves (that is function tabulated at selected values) and "continue"
analytic curves (that is function described with analytic formula) sharing
the same interface, so that they will be inter-operable at any level (e.g.
a Nelson-Siegel analytic curve fitted on Treasury bonds can be used instead
of knotted Libor curve). Anyone has such a piece of software ready to be
contributed? ;-)
c5) class CTenor. We can add this, but I don't see the reason to
discriminate between BusinessDay and Day. Day could be enough, it's the
holiday that make the difference (LONDON calendar has its holidays,
NOMARKET calendar has no holidays)

d) folder FFTS\holiday
we may work to merge here

Some general comment:
i) we prefer Exception instead of return( HUGE_VAL ).
ii) I've also seen your C++ test: C++ is better (more general) than our
Python approach, so everybody is welcome to port the available tests from
Python to C++.

As a final note I suggest you take a look at our coding guidelines: Gilbert
is working on that, for the time being http://www.geosoft.no/style.html is
a good starting point.
QuantLib itself is not conforming to its own coding guidelines, but we are
working on that ;-)


ciao -- Nando

[Ferdinando M. Ametrano-2]

Hi all

Bernd  wrote:
>We have python for scripting (other such as perl, java etc can be
>added over time leveraging swig) As far as visual working with the data
>is concerned I prefer spread sheets (Excel to be precise and I will
>contribute the sceleton of an excel interface soon).
I really look forward to the skeleton of the excel interface. Have you
considered to use SWIG core API for this task? I have no expertise on SWIG,
but I like leveraging ;-)

>  Interfaces to matlab,
>octave, R, etc  are essentially trivial to write which will address
>another area of use.
That's interesting too since I've never used matlab/octave and I would like
to start using them for/with QuantLib

>spread sheet interfaces (Excel, Applix,
>Star office, Gnumeric, Kspread).
I've used Applix API in the past for using C++ code, but from the little
I've seen Excel is different. Is there any common pattern between Star
office, Gnumeric, Kspread?

ciao -- Nando