I'm starting this thread as a home base for enhancement suggestions for the tool. I'd like to have one place to collect them so they don't get lost amid other discussions, so here's my request: if you have an enhancement suggestion, post it in this thread. Feel free to start another thread to discuss the suggestion in more detail, but point to it from this thread. No promises from me, of course - this is a spare-time project for me. But the best way to discuss enhancements is to start the discussion here. Thanks! Nathan
Suggestions: 1 - provide numeric output as csv file of result calculations 2 - provide batch input. - For generating series of trades for test when using ORC as pre-screening tool in trade development. To use RTT as an example - i can generate series of trades with 20, 30, 40... DTE, than upper long being 2%, 3% 5%... OTM etc. It is easier to feed ORC with such a fies, even with Copy-Paste, than enter each trade separately. 3 - provide access to last 5 result graphs within the program itself for easier comparison. It would be nice to have graphs overlapping capability too. I have other suggestions too : ) but they are beyond what I think can be reasonable in free version.
Thanks, Marcas. If I understand correctly, you want to evaluate a single trade with the ability to vary strike date on the trade and strike price on one of the positions. What are you looking for when you then compare the resulting charts?
More than that. I'd like to use ORC as, to say, pre-screening tool in developing/improving trade. I'm not sure how it will work in practice but idea is this. Let's stay with RTT as example. It is bearish leaning asymmetrical butterfly, maybe even unbalanced (i'm not trading RTT). Let's say that I want to come up with best setup. I will generate batch of many variants: different DTEs, different DITs, different expirations, different degrees of trade 'bearishness', wing widths, wing ratios and whatever else I can think of. Then I will test all variants in bullish, neutral, and bearish markets (splitting between grinding down markets and crashes etc). Your program runs pretty fast. After all this is done I can pick most promising combinations for more accurate backtesting on real data. Ability to overlap, or compare charts side by side is just quick and dirty (and even a bit risky) way to see what difference your change did when working with just few setups. You can more clearly see those curve shifts you were taking about in your presentation.
My impression of quick-and-dirtyness was not far off the mark; I don't think of graphical tools like this as good for screening. The values it computes as a byproduct of its work (mean price, mean P/L, median price, breakeven probability, etc.) can be useful, but I'd think the charts would be more of a distraction when you're pre-screening. As for coming up with a way to upload a configured trade, my inclination is to do that with XML. It's already doing that under the covers - the magic URL it generates from the risk chart is just a compressed XML description of the trade config, so adding another way to deliver that XML would be straightforward.
Thanks for sharing this great tool and asking for suggestions! As a longer term trader, I would find it useful to see the 95% confidence limits, or any other statistical measure of accuracy, for the expected P/L.
Thanks, PK. Confidence limits are associated with observed data - are you suggesting treating the P/L values from the simulated price paths as observations and showing the resulting confidence interval around the mean P/L?
I suspect that a predicted P/L of 300 USD of a position at 10 DTE may be statistically more accurate than a predicted P/L of 300 USD at 90 DTE and, consequently the dispersion of observed price paths should be greater and the resulting confidence interval around the mean P/L greater. Is this assumption correct?
What matters here is standard deviation, which appears in the numerator of the interval size computation. All other things being equal (including volatility), I'd expect a greater sd and a wider interval for the 90 DTE case.
PK, I've been playing with this a bit. The distribution of P/L values is not normal, so confidence intervals on that make no sense. The distribution of prices is lognormal, so we could compute a confidence interval on the log of the prices. Would that be at all useful?
Nathan, thanks for your prompt reply! I was also thinking about my question and came to the conclusion that it does not make sense. Not so much because of using log values to calculate confidence intervals but rather because of the high number (100k) of observations, which shrinks the intervals virtually to cero since they decrease more or less with the square root of this number. I found that there are other ways to circumvent this problem, but I think that it is not necessary because the answer is already in the Outcome Probability Chart. The number you provide is the P/L and to know what is the probability to obtain this P/L I looked up this number on the Outcome Probability Chart. As an example, I compared a 15 september position at expiration and 15 days earlier. The probability of break even increases from 26% to 71%; the expected P/L, however remains almost constant around 1.870; looking at the Outcome Probability Chart, the probability to obtain this return increases from 24% to 41%. If this makes sense to you, my suggestion would be to include the probability of expected P/L in the results section of the Outcome Probability Chart and/or mark the expected P/L with a dot/line on the Outcome Probability Chart. Thanks again for your feedback and aplogizes for my maybe confusing comments, Peter
I have one suggestion It would be nice if the background color or the graph color could be changed to a more contrasting color Right now the probability chart has a light yellow graph on a white background If one of them can be changed to black that would be a lot easier to see