Good thing coming out of this is now I can trade at 6 micros. Still got a few more to go before switching to emini. But i'm getting there. PnL looked fucked lol
Not sure I understand what went wrong. Are you saying that the algo encountered trading conditions that hadn't occurred in the period since it's been running ? Or had you made a change and this produced the error ? My background is in software development in the financial sector. First question you'd normally ask is - what changed ? EDIT - OK just read your previous post, basically the algo wasn't written to take into account the possibility of a partial fill, and therefore bought twice the size to close a short position, leaving it net long ? If so, seems surprising that this hadn't happened in the previous 6 months.
https://www.elitetrader.com/et/threads/i-give-up.375995/ I removed the last two trades so that my pnl curve doesn't get distorted. I'm not going to include outlier performance like that since that was technically in error, so I just used what it was supposed to make, which wasn't much. This journal is about evaluating a specific mechanical trading method, not the crap that can go wrong with algo trading.
To your question, yes techcnically what changed was that the market executed the target for the first initial lot (around 100ms) after entry, that it didn't have time to execute the target for the remainder of the lots properly. MOst of the time, the the algo enters the position (full or partial), but the algo has time to initiate a target on the whole position once it's cleared. Yesterday, market moved so fast that it didn't have time to properly calculate the right target on the remainder position. The algo actually mistaken the session to be over after the initial target is filled. WHen the algo finally executed the target for the remainder , it actually used the whole position resulting in a net long (naked). Some dev could probably just look at the code and decide what the error is in the position counter. But I just did a crude fix by putting a flatten logic right after the session ends alert. This way, even if there was an error, it will force closure of everything, including pending orders. I don't mind having crude solution since it is a rare occurrence. I'm hoping I dont see any more surprises with this algo. This the biggest challenge with trading algo, is that you can code your algo but you can only really test it in LIVE environment with real money. There's no way demo/market replay can pick up execution issues like this. Everyting is filed all at once in demo. So you have to edit as you encounter the issues as you trade moving forward.
Obviously the algo needs a 'clearing up' procedure, checks that there are no positions still open. But you learn this stuff via real world running, again surprised it's never arisen in 6 months of real time running.
Hilmy, Since you're trading an ORB system - did you read these two articles I linked you earlier? Maybe you'll find some ideas for further improvement. https://www.trade2win.com/articles/766-developing-trading-strategy https://www.trade2win.com/articles/768-developing-trading-strategy-part-2-a
I have, but his test period of 6 months on just one market are way too short to draw any significant conclusions. But I think his testing cases were pretty robust. When I back tested my strategy it was from 2020-2022 . I tested it on ES,NQ,YM,RTY. I had many iterations to my rules/settings cause I would find it broke down in one year and not the other.