Option pricing and Levy processes

[andrea loddo-2]

Hi,

I would like to have some opinions from you guys before starting implementing a model for pricing a plain Vanilla call option on a stock modelled via Levy process using Quasi Monte Carlo techniques. More precisely the distribution of the process is the Normal Inverse Gaussian distribution (NIG).
The most popular approach in order to simulate trajectories of this process is to consider a subordinated version of a Standard Brownian Motion where the time is driven by a Inverse Gaussian process. Now , generating the Inverse Gaussian paths is not a big issue, as I can use an algorithm based on generation of random numbers Chi-square distributed. The problem is how to sample the Standard Brownian Motion at time dictated by the Inverse Gaussian process.

I read QuantLib documentation and my strategy would be the following:

-Implementation of a Inverse Gaussian random generator and a sequence generator in order to get the subordinating process path.

-Generation of  random paths with the appropriate drift and diffusion using a gaussian sequence generator. My first idea is to use the PathGenerator class where the time grid is the subordinating process path. In this way I can sample the Standard Brownian Motion and get the distribution I want. (I am not sure about this though)

-Finally, in order to price the option I need two more things. Firstly, a PathPricer object which specify what kind of option I want to price. Secondly a MonteCarloModel object in order to effectively price the option using Low Discrepancy sequences.

Hope this makes sense.
Your opinion would be much appreciated.

Andrea.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

Hi Andrea,
        apologies for the delay. Between my real work and releasing version
0.8.0, I have accumulated quite a backlog of posts to reply to. Anyway,
here we go:

On May 17, 2007, at 5:44 PM, Andrea Loddo wrote:
> I would like to have some opinions from you guys before starting
> implementing a model for pricing a plain Vanilla call option on a
> stock modelled via Levy process using Quasi Monte Carlo techniques.
> [...]
>
> I read QuantLib documentation and my strategy would be the following:
>
> -Implementation of a Inverse Gaussian random generator and a sequence
> generator in order to get the subordinating process path.

Ok.

> -Generation of  random paths with the appropriate drift and diffusion
> using a gaussian sequence generator. My first idea is to use the
> PathGenerator class where the time grid is the subordinating process
> path. In this way I can sample the Standard Brownian Motion and get
> the distribution I want. (I am not sure about this though)

I understand that the sampled time grid will vary for each path. Is
this correct? If this is the case, the above approach is correct in
principle (and it could be used for prototyping the calculation) but
it's not the most effective since you'll have to instantiate a
different path generator for each path. And we're talking of a
framework which is not particularly optimized already... also, some
path pricers might get confused if they try and extract time
information from the path. For instance, the last node---the one at the
maturity T---would not contain T, but the corresponding subordinated
time (if that is the correct term.)  If the path pricer tried to
discount the payoff using that time, the result would not be the right
one.

Another approach you might want to pursue (as usually, if I haven't
completely misunderstood the problem) is to create a decorator that
turns a stochastic process into the corresponding Levy one.  Such class
would inherit from StochasticProcess1D, take another process, and
forward calls to such process after having mapped time according to the
subordinating process. Something like:

class LevyProcess : public StochasticProcess1D {
   public:
     LevyProcess(boost::shared_ptr<StochasticProcess1D> underlying,
                              ... /* parameters needed to initialize the
subordinating process */)
     : underlying_(underlying) { ... }

     Real evolve(Time t0, Real x0, Time dt, Real dw) const {
         Time dT = ... // sample the increment of the subordinating
process given the actual dt
         // same for t0
         return underlying_->evolve(T0,x0,dT,dw);
     }

     ... // other methods
};

The tricky part would be to keep track of the subordinating path, of
course (i.e., for mapping t0 to T0, one has to know what path one is
sampling.)  But the big advantage would be that one could then reuse
the existing machinery (path generators, path pricers and such)
unchanged, since this process could simply be substituted for the
original one.


> -Finally, in order to price the option I need two more things.
> Firstly, a PathPricer object which specify what kind of option I want
> to price. Secondly a MonteCarloModel object in order to effectively
> price the option using Low Discrepancy sequences.

Yes. As for path pricers, I think you can reuse existing ones. As for
the MonteCarloModel, the existing one might not work in your approach
since it takes the path generator upon constructions and there's no way
to replace it when the time grid changes. This could be fixed by using
a self-modifying path generator which re-samples its time grid after
sampling each path. In the approach I suggested, the existing
MonteCarloModel would work unchanged.

Hope this helps,
        Luigi


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[andrea loddo-2]

On 6/2/07, Luigi Ballabio <[hidden email]> wrote:

I understand that the sampled time grid will vary for each path. Is
this correct?

Correct!

Another approach you might want to pursue (as usually, if I haven't
completely misunderstood the problem)

You haven't.

is to create a decorator that
turns a stochastic process into the corresponding Levy one.  Such class
would inherit from StochasticProcess1D, take another process, and
forward calls to such process after having mapped time according to the
subordinating process. Something like:

class LevyProcess : public StochasticProcess1D {
   public:
     LevyProcess(boost::shared_ptr<StochasticProcess1D> underlying,
                              ... /* parameters needed to initialize the
subordinating process */)
     : underlying_(underlying) { ... }

     Real evolve(Time t0, Real x0, Time dt, Real dw) const {
         Time dT = ... // sample the increment of the subordinating
process given the actual dt
         // same for t0
         return underlying_->evolve(T0,x0,dT,dw);
     }

     ... // other methods
};

The tricky part would be to keep track of the subordinating path, of
course (i.e ., for mapping t0 to T0, one has to know what path one is
sampling.)  

I have been thinking a lot about it and it is tricky indeed. What I can say is that the sampling of the increment dT should be done within LevyProcess.  This is doable. One idea could be an additional private member such as an Inverse Guassian sequence generator, which I have already implemented.

The problem is how to keep track of the current dT for a subordinating path AND the the subordinating path in itself.  nextSequence() (for the next subordinating path ) must be called at some point in time. The problem is how and when.

Concerning the path, a possible idea but definitely not nice at all would be for example a counter that every time evolve() will be called adds up one and gives which of the sample of the current subordinating  path it should  be used. 

Then  in some way  I should take into account also which simulation  is being processed by MonteCarloModel. Maybe this counter can be reinitialized to 0 every time a path is completed, which means when the counter is equal to the dimension.

Although it is not an elegant solution at all, it might work, I think.

Thanks very much for you help, Luigi. It has been  very useful.

 
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

Hi Andrea,

On Tue, 2007-06-05 at 12:41 +0100, Andrea Loddo wrote:
> On 6/2/07, Luigi Ballabio <[hidden email]> wrote:
>         Another approach you might want to pursue (as usually, if I
>         haven't
>         completely misunderstood the problem)
>
> You haven't.

Glad to hear it.

>         is to create a decorator that turns a stochastic process into
>         the corresponding Levy one.  
>        
>         The tricky part would be to keep track of the subordinating
>         path, of course (i.e ., for mapping t0 to T0, one has to know
>         what path one is sampling.)  
>
> I have been thinking a lot about it and it is tricky indeed. What I
> can say is that the sampling of the increment dT should be done within
> LevyProcess.  This is doable. One idea could be an additional private
> member such as an Inverse Guassian sequence generator, which I have
> already implemented.
>
> The problem is how to keep track of the current dT for a subordinating
> path AND the the subordinating path in itself.  nextSequence() (for
> the next subordinating path ) must be called at some point in time.
> The problem is how and when.

Yes. I've been thinking along the same lines. It seemed a neat idea, but
it forces you to embed a counter in the process. Which is not neat. It
would work fine if the process itself contained the path generator and
was asked for its own paths, but that would be quite a refactoring---and
we should do some analysis to check that it doesn't have other
disadvantages.


For the time being, maybe the best solution would be to pass the
subordinating process to the path generator.  This way, the generator
would call nextSequence() at each path, pass the sampled times to
StochasticProcess::evolve(), and store the results in the path together
with the real times.

The above might be added to the existing PathGenerator, but it should
continue to work in the old way (and with no great loss in efficiency)
when no subordinating process is passed. Otherwise, we can code a new
generator, but it would duplicate most of the code of the old one, so
I'm not particularly keen on this.

Later,
        Luigi


----------------------------------------

Things should be made as simple as possible, but no simpler.
-- Albert Einstein



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[cuchulainn]

> is to create a decorator that
Another posibility is to define a Mediator that talks to

 

- GBM object

- Levy object

 

and let it do what it has to do.

---

From: [hidden email] on behalf of Andrea Loddo
Sent: Tue 05-06-2007 13:41
To: [hidden email]
Subject: Re: [Quantlib-users] Option pricing and Levy processes

On 6/2/07, Luigi Ballabio <[hidden email]> wrote:

I understand that the sampled time grid will vary for each path. Is
this correct?

Correct!

Another approach you might want to pursue (as usually, if I haven't
completely misunderstood the problem)

You haven't.

is to create a decorator that
turns a stochastic process into the corresponding Levy one.  Such class
would inherit from StochasticProcess1D, take another process, and
forward calls to such process after having mapped time according to the
subordinating process. Something like:

class LevyProcess : public StochasticProcess1D {
   public:
     LevyProcess(boost::shared_ptr<StochasticProcess1D> underlying,
                              ... /* parameters needed to initialize the
subordinating process */)
     : underlying_(underlying) { ... }

     Real evolve(Time t0, Real x0, Time dt, Real dw) const {
         Time dT = ... // sample the increment of the subordinating
process given the actual dt
         // same for t0
         return underlying_->evolve(T0,x0,dT,dw);
     }

     ... // other methods
};

The tricky part would be to keep track of the subordinating path, of
course (i.e ., for mapping t0 to T0, one has to know what path one is
sampling.)  

I have been thinking a lot about it and it is tricky indeed. What I can say is that the sampling of the increment dT should be done within LevyProcess.  This is doable. One idea could be an additional private member such as an Inverse Guassian sequence generator, which I have already implemented.

The problem is how to keep track of the current dT for a subordinating path AND the the subordinating path in itself.  nextSequence() (for the next subordinating path ) must be called at some point in time. The problem is how and when.

Concerning the path, a possible idea but definitely not nice at all would be for example a counter that every time evolve() will be called adds up one and gives which of the sample of the current subordinating  path it should  be used. 

Then  in some way  I should take into account also which simulation  is being processed by MonteCarloModel. Maybe this counter can be reinitialized to 0 every time a path is completed, which means when the counter is equal to the dimension.

Although it is not an elegant solution at all, it might work, I think.

Thanks very much for you help, Luigi. It has been  very useful.

 
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users