Hi,
I'm a newbie to the QuantLib library (but have been a quant for several years) and really like most of the QuantLib structure but have a particular suggestion that would make the library much more usable from an integration & system development perspective.
The library is currently devised (from what I've seen) s.t. the market data is given to the model or instrument as a specific type or set of types. So, the ubiquitous IR swap is given a specific YieldTermStructure, the Black model is given a vol & discount rate etc. I term this pattern the PUSH method. In it, the business/quant knowledge specific to the model is split between the model code (where the data is used) and the calling code (where the data is constructed and allocated to the model.
The benefit of this method is simplicity and the easy ability to follow the dependencies of a given price.
However, for system development and more complicated products, I much prefer the PULL method. In this pattern, a generic market data collection object is passed to the model and the model itself determines which specific data is required for pricing.
I'll just outline some of the benefits of this approach:
1) The information on the types of market data that are required is concentrated in a single place - the model code. There is no need for a calling system to have code specific to this.
2) It is simple to switch between market data environments - instead of having to update the handles to every bit of market data, you simply update the handle to the market data collection object. Then all instruments can be re-priced with no need to recreate the models.
3) You don't - necessarily - have to create a model externally. If you specify a default model type for a given instrument, the model can be constructed internally (the model spec is retrieved from the market data collection object). This can be very handy when switching between two different models in a system as the interface stays the same,
e.g. the release cycle of the calling system(s) does not have to be synchronised to the library and switching models becomes trivial.
4) For more complicated instruments, you might have an option which can be exercised into 2 or more derivatives. Instead of creating a model which contains a model (or more than one), each of which requires specific market data, you can simply let the default model be used for each of the underlying derivatives.
5) Developing models becomes simpler. If you need another argument/parameter, you simply register a value or object against the market data collection object and retrieve it internally from the market data collection object - no need to change the interface.
Has anyone had this discussion in the past? I've read through all the documentation I could find and read no mention of this. Perhaps I've been remiss and this is all explained somewhere. Or perhaps there is another project specifically for this.
I believe this could be implemented in a simple manner, in addition to the current interface.
It would require an additional constructor for all instruments/models (stoch processes) that supported this facility. It would also require additional descriptive variables within those models (so that the model knows which yieldcurve or which vol surface is needed). We'd also need some small additions to allow a change in the market data object (pointing to a new set of market data) to be passed onto the specific yieldcurves, vols etc. However, there would be no compulsion to use this new facility and no change to anyones existing calling conventions. It could be introduced slowly - no existing instrument or model would HAVE to support this type of access.
I'd be prepared to do the necessary work for this. I've developed in libraries that allow this facility before. Usually the only tricky part is determining the descriptive variables. For example, a model requires a EUR yieldcurve - but which one? EUR Libor or Euribor? Do we require a discounting curve or a forwarding curve?
Does anyone have any objections? Or any additions / comments or questions? I seriously believe that this would add substantial value to the project.
Regards,
Simon
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Locked
ExampleInterface.h (10K)