Here are some thoughts after spending time with Option Risk Calculator. First of all big thanks to Nathan for creating this tool and making it available to public. So my idea to use Option Risk Calculator was this: create some basic trade, lets say: ATM put butterfly, and test it in different environments, to see how it performs in various DTE's, various wing lengths (in symmetrical, broken wing and asymmetrical combinations). Then go to OTM butterflies and then to more complicated trades like double and triple butterfly and then jump to split top butterflies etc, etc. Before start lets look at tool itself. Is it right tool to get the job done and, if so, how to use it? In my opinion it can not be used to do any serious evaluation of real trades. Why? Because there is not enough parameters to tweak to get close to real market conditions. In Nathan's presentation Jim asked about using different historical distributions – yes, it would be nice to have it but, as per author's explanation, it would result in significant increase in time calculation, I'd prefer it stay the way it is. On my side I'd like to have direct control of volatility skew which, probably, had the same practical effect – more extensive and longer calculation time. On other hand I can use “Projected Stock Price Growth Rate (annual %)” field to emulate bullish or bearish market (except volatility skew changes). For above reasons I also think that usage of data from real option chains to feed ORC is pretty useless and to get best results I have to leave 'Premium” field empty and let ORC calculate it's own prices. Similarly expiration date is also meaningless, it can be any date. The only thing that matters here is day span between “Trade Start Date:” and “Strike Date” fields. With this in mind I started my tests from common 50/50 BFly. I was interested in only two output numbers: “Mean P/L” and “Probability of breakeven”. I set spreadsheet to capture results and started testing. I expected it to be tedious job but after just few tests I realized it will be plain-impossible to finish this task, not to mention testing other strategies. Why? There are too many clicks to get single pair results. The process is too prone to mistakes. Single test (let's say 50/50 Bfly, 70 DTE, in bullish market) should be run couple times to assure better output (aka that pair that is spit out doesn't come from tail), thus increasing number of clicks and risk of mistakes. 100K samples is max for ORC, you can not increase this number. At times I did get wide results showing me once positive p/l, other - negative, on the same inputs. You should do multiple runs for more reliable results. Nevertheless I managed to finish 50/50 70DTE butterfly. I also asked one of CD members to run the same test on market data. As expected results were way-way-off. True, life data were very small in comparison to, also small, test data, but we can assume that: I did some mistakes in my tests or other member generated wrong data or we had a 'bad luck' getting portion of data that were bad (means rest of life results are closer to test data). Actually we can not say anything about relationship between ORC and life data without performing extensive research. But also it doesn't really matter here as my goal was to explore direction of changes of trades in different configurations in various markets than obtaining concrete numbers. For those we have to go to market data. If above exercise worked, it would be nice (fast) screen to find promising configurations for future investigation without necessity to back-testing all of them. But it didn't work. For that, for ORC to work for me, I would need ability to feed program with input file containing all desired parameters (easy to generate) and get results written to output file (easy to analyze). Without this (and other functions) capabilities of OCR are limited to single strategies (for more patient traders than I am). I didn't meant to complain about ORC and I am not. I still appreciate Nathan's work and time he spend explaining it. I still admire speed of this software. I had vision how I can use this tool in my research and it didn't work out. I have to take different path.That's it. Attached is raw spreadsheet with my results. In cells first number is mean p/l, second – win rate. You see that after doing 15DTE I had enough and skipped right to 70DTE ( I had partial life data for that to compare) with understanding that it is not the way to go. Or I did something wrong here or misunderstood something...

Wow, Marcas... the Option Risk Calculator, with its simple probability model and strictly interactive interface, is a pretty rough force-fit to your trade-testing requirements. I'm glad you found it interesting enough to try, though.

I know, I know... Now I have dilemma: should I start building Monte Carlo for my needs or work on back-tester? Both options have unique properties and I want all of them! It was a fun though : ) Thanks

IMHO: There are two sticky wickets here: 1) What cumulative distribution function best fits the projected Time frame. 2) What will the volatility surface be at each point on that CDF function.

Garyw, Ice101781, I did find that my knowledge of statistics is close to none. I will have to make it up in the near future but for now I give a shot at putting up program anyway. ad1. do you mean distribution? I use std normalized distribution (I think : ) with possibility to use different types in future. Cumulative distribution is just calculation of area to the left. How calculation method can have significant impact here? ad2. that is a guess, to get a grasp of strategy we can project VolSkew the way we desire. BTW. I think if I have known distribution curve I don't need to use Monte Carlo at all to calc expected return for diff market conditions.

Marcas: My ramblings... ad1: I currently use a Normal Distribution for my CDF. This is easy and simple. BUT likely NOT the best choice for each Time period! -- Nathan, also uses Normal Distribution (per my limited understanding). ad2: The largest variable for this is likely the choice of sticky strike, VS sticky moneyness (or more obscure morphing of target point volatility) {More so than Volatility Surface per-se) [I currently use sticky strike -- The simple TOS-like method, but will likely change once I have a deeper understanding of issues] I do NOT use Monte Carlo either. I use the CDF to solve directly (with the ad2: for the iv input). -------------------------------- An attempt to "test trades" seems to be unsolvable without an extremely large and good sample size of "realistic trades". --- The whole notion of ad1: (all samples fit the distribution), infers, you will need a very large sample size to gain any confidence of being in the ballpark. This is made worse by ignoring direction (trend), and understanding that Normal may not be the optimal distribution. BTW: This is still weighing heavily on my mind. -- I would like to improve my handling of this area. (My knowledge of Statistics is very poor)

I'd say it is not the best choice. Period. But I don't mind for now for reasons below. I'm not there yet, at least not in my work progress. Gary the way I'm setting it up is that I don't care much about real data. I create my own VolSkew the way I want and see impact of changes on trade. I don't need to mimic real data, all I'm interested is capturing trends. I know that changing distribution type will give me different numbers but trend suppose to stay the same (as per direction, not magnitude). I save market data for later. This will be more manual (?)