[Quantlib-dev] System interface

[Simon I. <s.i...@gm...>]

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