Posted by
andrea-110 on
URL: http://quantlib.414.s1.nabble.com/One-question-about-instrument-engine-pathpricer-tp13421p13423.html
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
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev