@Big AAPL I used the term discretionary very loosely in that the methods is pretty mechanical. But coding in the larger time frame elements I know will take time. Mostly in the error-exception points. As for the reversal, that is the next thing I am going to incorporate. To me it silly to ride down something you know is wrong and more importantly the missed opportunity of riding a good wave, the bounce and the retest and the bounce again, i.e. 5-6 trades in a trending situation for this system.
@MarkBrown, Yes, generally, a larger timeframe and daily S/R. I.e. the premise time frame is busted AND the larger time frame premise too. I could add the averaging down is less than 10% of the trades, because I use a trailing adjustable stop (TAS) so slightly positive trades tend to get kicked out on reversals. But as you know, TAS is one time adjustable at IB. If I could have N number of adjustments, then I could develop an alternative. In general, I am trying to figure out the mechanics of position reversal versus the averaging down method to scratch.
@JSOP As for blowing up, it could be as simple as a string of the large stops. Since they are so large, a string of 5 would be pretty damaging. But that would be pretty bad and I just have not had it happen, but it could. Hence the waiting. I agree on the "cut the losses". Implementing them is a bit more nuanced, imo. My current thinking is to proceed with developing a reversal mechanism next. The main problem I encounter is the nature of ES. As you probably know, there are a lot of "flush outs" that occur and price then reverts back to a "mean" short term. In fact, they really need to be expected as the normal, imo. Frankly, it is a bit harder to figure out on ES so I did this method first. Also I can limit the trades to reduce the marginal losers, but one of the premises of the system is getting a higher number of trades. So it is a trade off.
@SunTrader As for timeframe, I don't use tick bars. Since I am not trying to compete with the professionals and the system is designed to work over a standard internet connection and a retail platform, a lot of that data seems too granular to react to live and get orders in and executed. As for testing, it was my profession and my college education, so I take a much larger and formal approach than most. Given the nature of the system, I am only forward testing in sim before live. I could go into the reasons why, but it is not worth trying in a forum, but suffice to say, the effort versus validation is the main tradeoff. In other words, I am focused on getting traction first and system analysis secondary. After I get traction, I can fine tune.
So I think this leaves me with the following conclusions.
1) Implement the reversal mechanism. It will be the 4th or 5th time. I probably just need to KISS. EDIT: I realized I already have a system. KISS, just take the loss and get back into the trades! That will keep the complexity down.
2) Do the analysis on the number of trades versus loss trades to find an optimal range
3) Start the coding framework for the parts I know I want. There is a lot of work there.
4) Do the analysis of the reversal versus average down methods, then take a step back and choose a set of solutions to implement and usage test, stress test and boundary test.
I will probably post when the March ES contract expires. Also at that time I will be ready to fund this system.
Thanks everyone for your responses. It helps to have others comment to think through the details.
BB
PS: Before anyone chimes in with the Sim versus Live, psychological and realism factors, I have a lot of experience live trading (decades and 6 digit swings). So working 4 and 5 digit swings is manageable. Also 95% of the trade "executions" are through the bid-ask threshold, so I am not relying on getting "jump to the top of the order que" magic fills. And I do have real swing trades going and a whole other system being developed there.
have at it. Otherwise tick or at least 1 minute needs to be used to even attempt to come close to what might transpire.