MakeMCEuropeanEngine<PseudoRandom>

[Frank Hövermann]

Hi there!

When I change the value which is passed to .withTimeSteps starting from 1 to, say, 5 in the case of non-flat vol term structure (but flat skew) which is defined by 5 points on the time scale, the value 1 results in a plain vanilla call option's value which corresponds to the start vol (all else being equal). Increasing the number of time steps the option's value seems to approach the value of the closed form solution where the speed of convergence depends on the particular shape of the term structure in the neighborhood of maturity.

 

I would expect, especially in the case of one time step for this plain vanilla call, the vol to be taken as the terminal vol not the initial one. Am I wrong?

 

Regards

Frank

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

Hi Frank,

On Thu, 2007-11-01 at 22:12 +0100, Frank Hövermann wrote:

> When I change the value which is passed to .withTimeSteps starting
> from 1 to, say, 5 in the case of non-flat vol term structure (but flat
> skew) which is defined by 5 points on the time scale, the value 1
> results in a plain vanilla call option's value which corresponds to
> the start vol (all else being equal). Increasing the number of time
> steps the option's value seems to approach the value of the closed
> form solution where the speed of convergence depends on the particular
> shape of the term structure in the neighborhood of maturity.
>  
> I would expect, especially in the case of one time step for this plain
> vanilla call, the vol to be taken as the terminal vol not the initial
> one. Am I wrong?

No, you're right. The problem is in the way that the Black-Scholes
stochastic process is discretized. By default, it uses Euler
discretization, which at each step simply takes the initial value (see
<ql/processes/eulerdiscretization.cpp>.)  You can obtain the behavior
you want by defining another discretization (you can do it by cloning
the Euler code and modify it) that takes the terminal value. Once you
have implemented it, you can pass it to the BlackScholesProcess
constructor so that it overrides the default behavior.  If you want, you
can implement more refined behaviors, too (such as integrating the
variance, or using some predictor-corrector algorithm.)

Luigi

P.S. If you implement the new class and want to contribute it, I'll be
glad to add it to the library.



--

The nice thing about standards is that there are so many of them to
choose from.
-- Andrew S. Tanenbaum



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Frank Hövermann]

Hi Luigi!
Thanks for your quick reply and the hints for possible correction. I will
play around a little with the existing code and would be happy to
(hopefully) be able to contribute a version which suits better.

By the way, does MakeMCEuropeanHestonEngine behave similarly? Presumably,
yes?

Regards
Frank

> -----Ursprüngliche Nachricht-----
> Von: Luigi Ballabio [mailto:[hidden email]]
> Gesendet: Freitag, 2. November 2007 17:17
> An: [hidden email]
> Cc: [hidden email];
> [hidden email]
> Betreff: Re: [Quantlib-users] MakeMCEuropeanEngine<PseudoRandom>
>
>
>
> Hi Frank,
>
> On Thu, 2007-11-01 at 22:12 +0100, Frank Hövermann wrote:
> > When I change the value which is passed to .withTimeSteps starting
> > from 1 to, say, 5 in the case of non-flat vol term
> structure (but flat
> > skew) which is defined by 5 points on the time scale, the value 1
> > results in a plain vanilla call option's value which corresponds to
> > the start vol (all else being equal). Increasing the number of time
> > steps the option's value seems to approach the value of the closed
> > form solution where the speed of convergence depends on the
> particular
> > shape of the term structure in the neighborhood of maturity.
> >  
> > I would expect, especially in the case of one time step for
> this plain
> > vanilla call, the vol to be taken as the terminal vol not
> the initial
> > one. Am I wrong?
>
> No, you're right. The problem is in the way that the
> Black-Scholes stochastic process is discretized. By default,
> it uses Euler discretization, which at each step simply takes
> the initial value (see
> <ql/processes/eulerdiscretization.cpp>.)  You can obtain the
> behavior you want by defining another discretization (you can
> do it by cloning the Euler code and modify it) that takes the
> terminal value. Once you have implemented it, you can pass it
> to the BlackScholesProcess constructor so that it overrides
> the default behavior.  If you want, you can implement more
> refined behaviors, too (such as integrating the variance, or
> using some predictor-corrector algorithm.)
>
> Luigi
>
> P.S. If you implement the new class and want to contribute
> it, I'll be glad to add it to the library.
>
>
>
> --
>
> The nice thing about standards is that there are so many of them to
> choose from.
> -- Andrew S. Tanenbaum
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Frank Hövermann]

Hi Luigi!
I've thought a bit about changing the discretization scheme for a
StochasticProcess1D at least. I think one should define a new abstract class
Discretization outside of StochasticProcess(1D) which should carry the
framework of a general discretization scheme and could inherit to derived
classes such as a new EulerDiscretization. Also
StochasticProcess(1D)::evolve has a very specific form which could be a
property of the (Euler)Discretization and not the process itself. As one can
easily see from the code, ::expectation, ::stdDeviation, ::variance only
carry over objects from the discretization method which suggests this to be
taken out to a new class which could show a more general behavior (Milstein,
integrating var, predictor corrector, Runge-Kutta, ...).

Could that make sense?

Regards
Frank

> -----Ursprüngliche Nachricht-----
> Von: Luigi Ballabio [mailto:[hidden email]]
> Gesendet: Freitag, 2. November 2007 17:17
> An: [hidden email]
> Cc: [hidden email];
> [hidden email]
> Betreff: Re: [Quantlib-users] MakeMCEuropeanEngine<PseudoRandom>
>
>
>
> Hi Frank,
>
> On Thu, 2007-11-01 at 22:12 +0100, Frank Hövermann wrote:
> > When I change the value which is passed to .withTimeSteps starting
> > from 1 to, say, 5 in the case of non-flat vol term
> structure (but flat
> > skew) which is defined by 5 points on the time scale, the value 1
> > results in a plain vanilla call option's value which corresponds to
> > the start vol (all else being equal). Increasing the number of time
> > steps the option's value seems to approach the value of the closed
> > form solution where the speed of convergence depends on the
> particular
> > shape of the term structure in the neighborhood of maturity.
> >  
> > I would expect, especially in the case of one time step for
> this plain
> > vanilla call, the vol to be taken as the terminal vol not
> the initial
> > one. Am I wrong?
>
> No, you're right. The problem is in the way that the
> Black-Scholes stochastic process is discretized. By default,
> it uses Euler discretization, which at each step simply takes
> the initial value (see
> <ql/processes/eulerdiscretization.cpp>.)  You can obtain the
> behavior you want by defining another discretization (you can
> do it by cloning the Euler code and modify it) that takes the
> terminal value. Once you have implemented it, you can pass it
> to the BlackScholesProcess constructor so that it overrides
> the default behavior.  If you want, you can implement more
> refined behaviors, too (such as integrating the variance, or
> using some predictor-corrector algorithm.)
>
> Luigi
>
> P.S. If you implement the new class and want to contribute
> it, I'll be glad to add it to the library.
>
>
>
> --
>
> The nice thing about standards is that there are so many of them to
> choose from.
> -- Andrew S. Tanenbaum
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev