Posted by
Ferdinando M. Ametrano-2 on
Jan 04, 2001; 2:49pm
URL: http://quantlib.414.s1.nabble.com/Quantlib-design-tp1657p1666.html
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