Please we need to start documenting QuantLib!

Cuchulainn · November 4th, 2010, 3:18 pm

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnA lot of (creeping?) features hereHow to prioritise? I would go forget it works (wrappers and interface)get it right (design patterns)get it optimised (SSE)After all, there's only 24 hours in one day, and evening hours are for Grey's Anatomy, yes?good idea!I'll dump some thoughts on an "independent simple interface", I'll look for standards. A function call signature is a combination of * contract parameters (strike, expiration, etc) * stochastic model (for B&S: constant vol value, consant rate value)We can probably define the interface as the oute-rproduct of the parameters of various versions of eitherWhat about usinghttp://www.boost.org/doc/libs/1_44_0/libs/func ... ex.htmlfor standard interfacesand Params for named parameters.Then these 2 libs would go a helluva a long way to creating friendly interfaces??

Cuchulainn · November 4th, 2010, 3:24 pm

Thijs and anyone,What about Heston as test casehttp://www.wilmott.com/messageview.cfm?catid=3 ... 70481Early results important.

renorm · November 4th, 2010, 6:17 pm

What outrun wants is doable. I might actually do it at some point, except SSE. There are many easier ways to optimize QL without using SSE.What Cuchulainn wants is not clear to me. Redesign? A new and improved clone of QL or completely new library? GOF Observer is an essential part of QL's OOP design. It can't be replaced without breaking legacy code.QuoteIt's not just a numerical library. Whether that's a good thing or not has been the object of much debate...Anyway, see chapter 2 here.I read it, but missed the debate. What were the alternatives? The first thing that comes to my mind is to keep accounting types (instruments, calendars, day counters) uncoupled from umerical types (pricing engines, processes, path pricers). MC engine doesn't need to know anything about day counting or Observer pattern. All it needs is a time grid of year fractions. Instruments or something else would be responsible for supplying an appropriate time grid and the most recent market data.

Cuchulainn · November 4th, 2010, 7:35 pm

QuoteWhat Cuchulainn wants is not clear to me. Redesign? A new and improved clone of QL or completely new library? GOF Observer is an essential part of QL's OOP design. It can't be replaced without breaking legacy code.More of a modest proposal. I am just giving my views on how it could be done.The QL community decides. The discussion started with documentation and using standard design and boost should hopefully help. Regarding Observer, you can keep the same interface and replace the internals by Signals, as my previous code. QuoteI would like to add B&S to define a second "function".Maybe better as 101 case. It is be up and running in a few hours. Exact solution and greeks. 6 Params and finish?What about Sitmo I could try it from C#. Will you make normal DLL?QuoteRegarding the interface, I vote as simple a possible, something likeextern "C"{double europeancall_heston_price( european call contract params, heston process params)}Even better!Quotebecause this allows for a uniform interface and easy linking to the lib from VBA, C, C++, python, R, php, Matlab and on both Linux and WindowsC# as well.

renorm · November 4th, 2010, 8:16 pm

Can't do anything nontrivial to the observer without total rewrite. QL is big and Observer has many children. It s easier to start a new projects and borrow bits and pieces from the old one. I am actually working on that.

Cuchulainn · November 4th, 2010, 8:40 pm

QuoteOriginally posted by: renormCan't do anything nontrivial to the observer Mediator (instead of MVC)PropagatorBGLdepending on the underlying graph.Java uses OO Observer; Microsoft uses Delegates, as does Signals.

renorm · November 4th, 2010, 10:53 pm

All that makes perfect sense. But Observer is a foundation of almost every class in QuantLib. Decoupling things from it is not possibleQuotewithout total rewriteIt is not about Observer alternatives, it is all about not breaking the legacy code. Observer interface is used in hundreds of source files.

lballabio · November 5th, 2010, 7:32 am

While we're on the subject of experimenting on redesign, I've set up a git mirror of the QuantLib repository at <git@github.com:lballabio/quantlib.git>.It should make it easier for people to experiment with the code, keep abreast of the changes in the official repository, but at the same time have version control and local branching for the various experiments.

renorm · November 5th, 2010, 8:09 am

Can we have smaller, specialized versions? Is it practical to split QuantLib into finite-difference, MC, LMM, equity, etc branches? It would make what Cuchulainn said easier to implement and test.

renorm · November 6th, 2010, 3:00 am

QuantLib has a lot of stuff from pre-boost times. As I remember correctly, the developers were planning to prune many math functions in favor of boost. But there is one problem. Boost special functions are designed for precision, not speed. Typical Monte-Carlo doesn't need 15 digit accurate Inverse CDF. In general, anything not critical for performance could be and should be delegated to boost and other high quality libraries.