One question about instrument/engine/pathpricer
Locked
One question about instrument/engine/pathpricer
 
|
Hi,
I have a question about the role of PathPricer / Instrument and engines in the MC framework. I have recently updated the experimental/mcbasket code but I feel I am doing something "wrong" in the code since I might have misunderstood the role of the above objects. It looks to me that the PathPricer is ultimately the object that is able to compute the "values" for a give stochastic path. The path prices usually needs some information coming from the Instrument (sometime the Payoff object, other times else) to be able to do this. And it is directly created by the engine for that particular instrument. An example of that is template <class RNG, class S> inline boost::shared_ptr<typename MCEuropeanEngine<RNG,S>::path_pricer_type> MCEuropeanEngine<RNG,S>::pathPricer() const { .... return boost::shared_ptr< typename MCEuropeanEngine<RNG,S>::path_pricer_type>( new EuropeanPathPricer( payoff->optionType(), payoff->strike(), process->riskFreeRate()->discount(this->timeGrid().back()))); } Now, my question is the following: it looks like an engine can only work with one pathpricer which can only work with one instrument. So for every new option (e.g. a digital option, or everest option, himalaya option, pagoda option) one needs to write (instrument, pathpricer, engine, makeengine) If the PathPricer was somehow "inferred" from the instrument, one could (maybe) get rid of all (maybe just some) of the engines (and makeengines) for a generic one. This is what I did try to do with the code in mcbasket, there is only one engine and the pathpricer for all instruments (inheriting from PathMultiAssetOption) is always the same. But I have a feeling I have missed some key points of the design (or the hidden implications of my idea) and I would be very happy to write a more compliant version of the code. ------------------------------------------------------------------------------ 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 |
Re: One question about instrument/engine/pathpricer
|
|
On Mon, 2010-03-15 at 12:49 +0000, Andrea wrote:
> I have a question about the role of PathPricer / Instrument and > engines in the MC framework. > > [...] > > It looks to me that the PathPricer is ultimately the object that is > able to compute the "values" for a give stochastic path. > The path prices usually needs some information coming from the > Instrument (sometime the Payoff object, other times else) to be able > to do this. And it is directly created by the engine for that > particular instrument. Correct. > Now, my question is the following: it looks like an engine can only > work with one pathpricer which can only work with one instrument. > So for every new option one needs to write instrument, pathpricer, > engine, makeengine Yes, I'm not very happy with it either. As you probably saw, that would be because different parameters need to be passed from the instrument to the engine to the path pricer. One way to bypass the problem might be the one you suggest, namely, > If the PathPricer was somehow "inferred" from the instrument, one > could (maybe) get rid of all (maybe just some) of the engines (and > makeengines) for a generic one. > > This is what I did try to do with the code in mcbasket, there is only > one engine and the pathpricer for all instruments (inheriting from > PathMultiAssetOption) is always the same. 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. 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. Later, Luigi -- What is written without effort is, in general, read without pleasure. -- Samuel Johnson ------------------------------------------------------------------------------ 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 |
Re: One question about instrument/engine/pathpricer
|
|
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 |
«
Return to quantlib-dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |