Re: System interface

Posted by Simon Ibbotson on
URL: http://quantlib.414.s1.nabble.com/System-interface-tp9820p9823.html

Hmm, would have been useful if I'd attached the file...

On 10/8/07, Simon Ibbotson <[hidden email]> wrote:

Okay, here's my first stab at sketching the implementation, I've attached a file showing the basic draft of the pattern.

 

There are several classes outlined - I've tried to follow the basic structure of QuantLib and derived from the basic classes... if I've broken a pattern irreparably, let me know.

 

 

The Termsheet class (deliberately left opaque), which supplies cashflows/payoff for the Instrument and information to resolve the market data.

The Instrument derived class which holds the payoff and cashflow arguments for the PricingEngine.

The PricingEnvironment which supplies the StochasticProcess and PricingEngine for the Instrument and the MarketDataCollection for the StochasticProcess.

The StochasticProcess derived object, which determines the type of market data required.

The MarketDataCollection class, which supplies the specific market data objects.

 

 

This is idealised, there may be cases where the Instrument does not require a StochasticProcess or PricingEngine and should simply get the required market data from the PricingEnvironment itself.

 

All comments are welcome,

 

Simon

 

 

On 10/3/07, Luigi Ballabio <[hidden email]> wrote:

On Fri, 2007-09-28 at 10:12 +0100, Simon Ibbotson wrote:
> 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. [...] 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.
>
> 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.

Simon,
       interesting idea.  However, I'm not sure that I'd jump into it right
now---I'm aiming for a 0.9.0 release by the end of the year and a 1.0
release shortly afterwards, with a couple of refactoring and some
maintenance work to be done before that.  In order to deliver the
releases, I'd keep your idea for later. Since, as you said, it's an
incremental modification (an instrument might implement both approaches,
right?) it can be introduced in later releases without breaking backward
compatibility (which we'll have to think about after we release 1.0)

This said, I repeat: interesting idea. Why don't you sketch the
implementation of one instrument so that we can go into details?

Later,
       Luigi


--

I hate quotations.
-- Ralph Waldo Emerson

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev