Re: Question on PathGenerator

Posted by Luigi Ballabio-2 on
URL: http://quantlib.414.s1.nabble.com/Question-on-PathGenerator-tp3287p3292.html

On 2004.09.03 10:11, Ferdinando Ametrano wrote:
> it's not just backward-compatibility. Calculating the asset values  
> even when you don't need them it is a waste of exp() computations  
> which is going to slow down the simulation.

Right, but we're calculating them already---right now, storing them  
would not slow down the calculation. I agree that it could prevent  
making it faster, which is an issue we might want to explore :)

My proposal:

 - have the StochasticProcess know whether it's working on S or log(S);
  this is done by implementing its interface correctly, where
  'correctly' is defined as:

  - when the process models S, drift(t,s), diffusion(t,s) and such
    mean the obvious thing;

  - when the process models log(S), drift(t,x) means drift(t,log(s));
    same for diffusion, variance and such;

- at this point, the stochastic process interface is transparent with
  respect to its proper underlying and the path generator just works
  by doing:

  x = ...; // (1) initial value
  for (...) {
      drift = dt*proc->drift(t,x);
      diffusion = rnd*sqrt(proc->variance(t,x,dt);
      x += (drift+diffusion);
      ... // (2) store the value?
  }

  where the exp have disappeared (of course, if the Black-Scholes
  process uses a local volatility surface, it will do the
  exponentiation inside drift() and/or variance(), so it doesn't gain
  anything--but other processes might.)  We still have to specify in
  (1) and (2).

- at (1) we have the problem of giving the above a proper initial
  value x0, to be deduced from the initial asset value; this is done
  by calling proc->underlying(s0), which is the identity function when
  S is modeled and the log function when log(S) is;

- at (2) we'd like to store asset values, but we don't want to
  calculate them needlessly. TimeGrid comes to the rescue: it has the
  possibility to specify that some time points are mandatory stops,
  while others are just intermediate steps.  At the mandatory times,
  we'll need the asset value anyway (they're fixing dates, exercise
  dates...) so that we don't save anything by not exponentiating--it
  would only be done later.  The intermediate points are only used
  for building a more accurate path when drift and diffusion are
  asset-dependent, but the asset value at those points is not needed.

  Therefore, we calculate and store in the path the asset values at
  mandatory times. Actually, I would go a bit further: if we pass the
  generator a time grid with 100 points and 10 mandatory times, it
  would return a path with 10 points, each of them being the
  cumulative result of the intermediate ones.  The values at mandatory
  times would be calculated by calling proc->observable(x), which is
  the identity function when S is modeled and the exp function when
  log(S) is (no, I didn't call it proc->assetValue---although I've
  been using 'asset value' until now for clarity, we might be modeling
  the short rate by using the dynamics returned by a calibrated
  Hull-White model.)

Thoughts?

Later,
        Luigi