Posted by
Luigi Ballabio on
URL: http://quantlib.414.s1.nabble.com/One-question-about-instrument-engine-pathpricer-tp13421p13422.html
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