Posted by
Luigi Ballabio-2 on
URL: http://quantlib.414.s1.nabble.com/Question-on-PathGenerator-tp3287p3297.html
Hello Walter,
On 2004.09.01 17:56, "Penschke, Walter" wrote:
> I tried to simulate a geometric brownian motion process, which I did
> define in my own class GeometricBrownianMotionProcess. Basically this
> class is derived from StochasticProcess and defines the methods drift
> and diffusion.
>
> The stochastic differential equation of this process is:
>
> dS = mue * S * dt + sigma * S * dz
>
> The problem now is that class PathGenerator from Quantlib (defined in
> pathgenerator.hpp) does not produce proper paths for this process.
> [...] the asset_ variable, which tracks the evolvement of the
> process, in my case S, within this method is adjusted as follows per
> step:
>
> asset_ *= QL_EXP(next_.value[i])
>
> This is correct if the Path variable (next_) is modelling a process
> defined on dS/S, i.e.: on the change of the process, rather than the
> process itself.
Yes. I've been aware of this for some time, but I still haven't found
the time to try and remove the assumption. Right now, PathGenerator can
only be used with a Black-Scholes process, which is hardly a happy
state of affairs--as there are in the library a couple of other
processes which suffer the same problem you found.
> For my GeometricBrownianProcess, which defines the process on dS, the
> line above in my (simple) opinion should be (May be that's not quite
> correct, but I hope you get the idea.):
>
> asset_ *= QL_EXP(next_.value[i] / asset_)
or more simply,
asset_ += next_.value[i];
> This would mean that I can't reuse the existing PathGenerator class,
> but I need to implement my own one which basically only differs in
> the line above. I think this code duplication is not nice and should
> be avoided if possible.
I agree. A new method should be added to StochasticProcess, so that the
above can be written as:
asset_ = process_->apply(asset_, next_.value[i])
where the process would take care of updating the asset value in the
proper way.
Then again, an ambiguity would remain---as of today, the generated path
stores asset variations, and not asset values. This implies that given
a path, it is not possible to use it properly without knowing whether
the variations are absolute or relative, i.e., without knowing which
process was used to generate it. The Monte Carlo pricers in the
library work under the implicit assumption that the paths they're given
were generated by using a Black-Scholes process--they would fail if a
process were used which modeled dS instead of dS/S.
It would make me much happier if the actual asset values along the path
were stored instead.
Thoughts?
Later,
Luigi