RE: Announcing QuantLib: a open-source library for quantitative finance

[Gilbert Peffer]

Hi Fernando,
I have read all the information on your web site and it looks really very
interesting. I also accessed the sourceForge site for QuantLib and looked at
all the available info. Furthermore I signed up with the dev and the user
mailing list. I have quite a few suggestions and also some questions, but I
need to look a bit more in detail at the source code and include files to
understand the logic you employed. Some very preliminary suggestions are

        - Include IMSL and NAG analytics interfaces. This will give the user the
possibility to access the most robust mathematical routines written under
the sun.

        - Estmiation and calibration methods such as maximum likelihood or
filtering

        - XMLing the structures is a great idea

        - A schedule class is very important, but I saw that you are already
working on that

        - I would suggest to add an ExchangeInstrument class, containing all the
exchange traded instruments for all instruments (futures, options, ...)
traded on an exchange

        - Add a <Quote> class that can be observed by objects such as yield curves
(for automatic live updates)

        - A class <StructuredNote> would be great, but I have a feeling that this
is highly non-trivial

        - Some other classes to think about and add are <Trade>, <Portfolio>,
<Flow>, <Index>, <Lattice> (sorry if I should have put something here that
has already been implemented)

        - A function parser would be excellent to have. That way, you can let users
input for instance more complicated cash flow patterns (for instance in
leveraged floaters, but in many other situations more)

        - An interface to MatLab is certainly a good idea, but can you distribute
applications written in QuantLib and using MatLab for graphical output to
users that don't have MatLab installed? If yes great, if no, we should look
for graphic freeware.

These are my some, as of yet unorganised thoughts to the topic. I will have
a look at the code over the weekend.

Best regards,

Gilbert

[Ferdinando M. Ametrano-2]

Hi all

Gilbert wrote:
>         - Include IMSL and NAG analytics interfaces. This will give the
> user the
>possibility to access the most robust mathematical routines written under
>the sun.
We can't. IMSL, NAG, Numerix, Panalytix, XXX APIs are copyrighted. We
cannot clone their interface if we want QuantLib to stand the test of time.
We can design our own interfaces, then anybody can provide wrappers for
proprietary libraries to be used in place of any part of QuantLib.
Besides to adopt non-free libraries may be a serious problem for student
and researchers. I don't want to force anybody to buy XXX analytics to use
QuantLib.

In the search of a Grand Numerical Library we will have some problem.
Even gsl (Gnu Scientific Library) is forbidden because of its licence (GPL).
Another constraint to consider is that I want QuantLib to be cross platform.

>         - Estmiation and calibration methods such as maximum likelihood or
>filtering
This means multidimensional optimization, that I plan for release 1.0. I
don't think 1.0 will deal with calibration, I think it will be plain
vanillas only.
Of course as soon as 1.0 is out we can work on more advanced issues.

>         - A schedule class is very important, but I saw that you are already
>working on that
Yes I hope Luigi and I will have it in January. Maybe I will post the
interface design before.

>         - I would suggest to add an ExchangeInstrument class, containing
> all the
>exchange traded instruments for all instruments (futures, options, ...)
>traded on an exchange
I agree.

>         - A class <StructuredNote> would be great, but I have a feeling
> that this
>is highly non-trivial
It's too early. We need term structure models

>         - Some other classes to think about and add are <Trade>, <Portfolio>,
Enrico is working on <Deal> (that will include a <FinancialIntrument>),
<Portfolio> (a collection of <Deal>s valued on the same curve/model),
<Book> (a collection of <Portfolio>s), <TradeGroup> (a generic collection
of <Deal>s, with no further constraints)

><Index>
Luigi and I are working on that. This class should provide an index fixing
estimate for all the models available

><Flow>
A cash flow schedule will be something like an array of <Flow>s, including
also the date handler structure, and an <Index> reference

><Lattice>
I'm thinking about a <Model> class that wraps what is currently available:
e.g. FiniteDifferenceModel<CrankNicolson<TridiagonalOperator> > (where
TridiagonalOperator is the discretization of a differential operator, e.g.
the one for Black Scholes equation)
On such a model you can rollBack an <Asset> without knowing about the
inners of <Model>

>         - An interface to MatLab is certainly a good idea, but can you
> distribute
>applications written in QuantLib and using MatLab for graphical output to
>users that don't have MatLab installed? If yes great, if no, we should look
>for graphic freeware.
I'm not good at that, but I would consider wxWindows (http://wxwindows.org/)
Anyway QuantLib is a library. I will support any attempt to build an
application on QuantLib, but I don't think the time is right to start
working on that.
QuantLib API will change a lot before 1.0
I personally use the Python interface and I think scripting languages are
good for this task.
Excel and MATLAB are so widespread I think is a smart move to support them.

There are a few border issues between a library and an application. While
the application in not a 1.0 goal some of them need careful planning from
the start. I found a few application issue in your message. The following
is a list:

>         - Add a <Quote> class that can be observed by objects such as
> yield curves
>(for automatic live updates)
This may be a natural extension of our design of yield curves as observable.

>         - XMLing the structures is a great idea
Thank you. Unfortunately it is only an idea. I never worked with XML,
everything to do.

>         - A function parser would be excellent to have. That way, you can
> let users
>input for instance more complicated cash flow patterns (for instance in
>leveraged floaters, but in many other situations more)
I completely agree, even if I have no idea how to write a parser.
This is not urgent since the parser is mainly to allow an end user of a
QuantLib application
to describe a complex cash flow pattern. As QuantLib developer you can
write ad-hoc code (not elegant I agree, but this is just to set priorities)


A great part of the excitement of an open source project is that you don't
plan everything ahead: you know the suggestion: "release often, release early".
Nothing is written in stone, so fell free to give me a strong feedback.
Even better provide working code, I'll do my best to make it fit with the
general design.
If your contribution is good it will even change the design.

ciao -- Nando