3
$\begingroup$

I have written some software to price a call option using Monte Carlo simulation.

It produces a price which is consistent with the model when I set the time step as recommended in a tutorial that I am following, which instructs to divide the expiration by 100.

I decided to experiment with the time step size and noticed that if I make the time steps further smaller by a factor of 10, the simulation does not produce the correct answer anymore. In fact the answer is way out (answer should be 10.45 but changing the time step gives an answer of around 70).

My question is whether this is expected behaviour from Monte Carlo simulations when the time step size is adjusted like this? If so, what is the theory behind this. It could also be that my implementation is wrong but I have followed Glasserman's book to letter in writing the software.

$\endgroup$
  • $\begingroup$ I added the link to the book in question, but it would be good if you explained what you are trying to price (I guess a call option), using what model (I guess GBM). As the code is probably quite simple, you could have posted it as well in your question, which would have helped. $\endgroup$ – SRKX Sep 1 '15 at 6:25
  • $\begingroup$ @SRKX, code added. $\endgroup$ – user16556 Sep 1 '15 at 6:27
  • 3
    $\begingroup$ are you sure that timestep*number of steps has been held constant? $\endgroup$ – Mark Joshi Sep 1 '15 at 6:29
  • 2
    $\begingroup$ @MarkJoshi, you are correct. The time step size and the for loop were out of whack. Thanks! $\endgroup$ – user16556 Sep 1 '15 at 7:26
1
$\begingroup$

You don't say anything about the model or discretization so it is a little hard to judge.

However, if you are using an exact discretization, the time step-size should be irrelevant.

If you are using an approximate one, the more steps you use, the more accurate it should get.

Possible sources of error: 1) random number generator is not good enough and this only shows up if you use a lot of steps 2) some term is not scaling correctly with step size.

$\endgroup$
  • $\begingroup$ I'd go for 2), he's probably no scaling the volatility of the steps correctly, which makes the underlying asset is far too volatile and hence the price of the option (I guess?) becomes higher. $\endgroup$ – SRKX Sep 1 '15 at 6:24
  • $\begingroup$ Yes that's what I expected but I'm not observing that. It must be my implementation that is wrong. The discretization is the usual Euler scheme and it is the standard Black Scholes pricing model. $\endgroup$ – user16556 Sep 1 '15 at 6:29
  • $\begingroup$ Try simulating the log spot instead of the spot itself. This way there will be no discretisation error. $\endgroup$ – AFK Sep 1 '15 at 18:15
0
$\begingroup$

I don't have any background in financial simulations or the Monte Carlo Algorithm, and I do not know about the program you wrote, which language you used, your background in programming, et cetera.

You might be observing some effects based on floating point numbers. If you make the step size smaller, the result of some multiplication will be smaller. You will most likely add that to some existing result, and you could lose precision in that step. Basically, adding a very very small number to a bigger number can cancel out the smaller number. Because the exponent of both numbers needs to be the same, the numbers will be shifted before the addition. After the addition, the result gets shifted again, and the very small part might be shifted away. Look up floating point addition and go through your code to clarify if this is the case.

You can also try to debug the code and calculate single steps with a calculator and compare that to your computer's result.

$\endgroup$
  • $\begingroup$ No, that's not the issue. As you can see I have marked the correct answer. $\endgroup$ – user16556 Sep 1 '15 at 17:43
  • $\begingroup$ it is not a bad answer though $\endgroup$ – Mark Joshi Sep 1 '15 at 23:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy