Naive MC method correctness

[HaroldRKingsberg]

I've run the Naive MC method here two different ways at this point: once using the current geometric Brownian motion concept and once with the closed-form solution concept. In both cases, I ran them about a thousand times apiece, and found the analytic solution only seemed to come up within the confidence interval 7% of the time at best. Additionally, the standard deviation of those runs is several orders of magnitude greater than the target.

(The code I've been running has been in the option_edits branch.)

I believe @petercwill identified something similar in Issue #6. I'm calling it a night as I have work tomorrow. If anyone figures out what we're doing wrong, please respond ASAP, since we're behind schedule here.

[HaroldRKingsberg]

I think our confidence interval may be:

$\mu{paths} + \frac{\sigma{paths}}{\sqrt{n_{paths}}}Z$

But I'm going off StackOverflow here.

[HaroldRKingsberg]

Specifically: https://quant.stackexchange.com/questions/17204/what-does-convergence-in-monte-carlo-simulation-mean

[mtran2011]

I found an error in the AnalyticEuropeanStockOptionSolver formula. I'm revising it and pushing to master @HaroldRKingsberg : please review this change I'm going to make now to AnalyticEuropeanStockOptionSolver and revert back if needed

[mtran2011]

I think we're good now with a small fix in AnalyticEuropeanStockOptionSolver and its tests.

I'm now looking at NaiveMCOptionSolver to see why we get a std dev of 2.46 while our target is 0.1

[HaroldRKingsberg]

@mtran2011 I wrote the analytic solver essentially by copying what you'd written in tests/analytic.py, and tested it against numbers generated by analytic.py. If there's a bug in AnalyticEuropeanStockOptionSolver, the problem's also in your original code.

I'm nearly positive the two ways are equivalent, the difference being whether or not you distribute exp(-rT) or not. I do prefer things the way you've changed them to -- fewer calculations -- but I'm pretty sure this wasn't a bug.

[mtran2011]

Actually the analytic solver did pass the test before so the bug, if any, wasn't there. I'm still looking at why so many of our MC-based values fall outside the target range

[HaroldRKingsberg]

It's because we've been foolish about this whole thing. What we want to do is specify max length of the confidence interval and the confidence level. We then keep creating paths until the confidence interval from our paths is within the max length. The confidence interval from the paths is calculated as the standard deviation of the paths normalized by the square root of the number of paths, multiplied by the Z-value.

So yes, the overwhelming majority of the paths will end up outside that confidence interval. However, the chance that the population mean will fall outside the confidence interval (sample mean +/- confidence interval) goes to nil.

[HaroldRKingsberg]

I can write this easily enough when I get home tonight.

[mtran2011]

I was the wrong one to put the formula for npaths and nsteps in there. After I do some reading, the algorithm and stopping criteria is like you said Harold, which is: ` while (sample std dev of the sampled payoffs > target stdev):

simulate a new path

get a new payoff from this path, add it to collection of sampled payoffs

update the std dev of the sampled payoffs ` npaths = O(epsilon^-2) and stepsize = O(epsilon) but we don't know the constant in this O(.) I put npaths=epsilon^-2 which clearly did not work

[HaroldRKingsberg]

This has been implemented as of commit fa5e2769b279abc30799de0c0c73cab8bd968930

It should be noted this is a really slow way of going about things: it's about 5 seconds to get a confidence interval of +/- 0.1 (95%), and about 25 to get a confidence level of 0.05. This came out to about 60,000 paths for the 0.1 interval, and 280,000 for the 0.05 interval.