Re: [Quantlib-dev] One question about instrument/engine/pathpricer

[Andrea <mar...@go...>]

On 31/03/10 17:09, Luigi Ballabio wrote:

> In your design, the instrument builds the path pricer and passes it to
> the engine, so the parameters don't need to be passed.  However, in
> doing so, you've coupled the instrument to the Monte Carlo method. On
> the one hand, the instrument (which used to model the real-world
> contract, independent of how it would be priced) now has to care about
> building a Monte Carlo path pricer (and in principle, has to take inputs
> related to MC calculations such as the number of steps, as well as
> inputs such as the stochastic process to use.)  On the other hand, once
> you've put the path pricer in the instrument arguments, you've ruled out
> using another, non-MC engine.

You are right.
The PathMultiAssetOption contains a method

virtual boost::shared_ptr<PathPayoff> pathPayoff()  const = 0;

That is 100% coupled with the MC engine.
If I wanted to price with a PDE, I would need to add something like

virtual boost::shared_ptr<PDE????> pdePayoff()  const = 0;

Which might be considered good or bad. I am not sure either way.

Maybe one could multiple inherit from each engine-base class that the product supports (e.g. MC or
PDE), rather than forcing all engines in the base class and then to all instruments.

Alternatively, could we register a factory of path pricers against Instruments so to move the method
pathPayoff() elsewhere?

Something like

shared_ptr<PathPricer> PathPricerFactory::create(shared_ptr<Instrument> ins);

I am not too good with design patterns, but this sounds like a visitor issue. Would it help?

> Unfortunately, I don't have a solution for this.  One road to try might
> be to write a template engine that just passes the entire arguments
> structure to the path pricer; something like
> 
> template <class InstrumentType,
>           class PricerType>
> class McEngine : public InstrumentType::engine {
>     ...
>     shared_ptr<PathPricer> pathPricer() const {
>         return new PricerType(
>             dynamic_pointer_cast<InstrumentType::arguments>(
>                 getArguments()));
>     }
> };
> 
> after which the path pricer can extract the needed parameters from the
> argument structure.  You'll probably have to add another template
> parameter for the type of stochastic process to use in order to
> instantiate the path generator.
> 

Here the path pricer is a template argument, so I don't need to *write* a new McEngine, but I still
need to write the code to *instantiate* each new engine. Which is a step in the right direction.

Still need to think about it...

Andrea