Anyone who's put up with my ravings long enough knows I am singularly unimpressed with forward testing as a way to verify an EA. Run an EA for 2 weeks (which is longer than many do) and you know how it performed in those two weeks. I want to know how it behaved over a lot longer period than that, and I want to be able to test different inputs and different code. I want a good backtest.
Empty4 has Strategy Tester. Nobody trusts it but it's slightly better than nothing. But ST can't test a multi-pair strategy like Shelley. Neither can Tradestation, my go-to backtester. EAs can't backtest it because they only execute in realtime.
But indicators CAN.
As an experiment I took Simple Shelley 1t and converted it to an indicator that tracks trade profits. I dump the results to a file, and transfer those to Excel for plotting.
These are VERY PRELIMINARY results -- it took much longer than I anticipated to mash the EA into indicator shape, and I have some other commitments that mean I won't be able to spend much more time on it for a while. I think they're correct (or close), and I wanted to share them so we could get a better idea for how Shelley performs.
I based this on Simple Shelley -- and I can't use MPTM on an indicator -- so these tests currently have only a 20-pip adaptive TP and a 30-pip adaptive SL. No jumping stops, no timeout, no nothin' except TP and SL. So one would hope we could improve upon these results.
So how'd it do? I ran it on M15 charts to get reasonably accurate execution, which limited me to 3 months of tests. Since it runs only once every 15 minutes, it is NOT totally accurate -- the basket might have touched the TP within the M15 candle and then reversed, and you wouldn't see that. M1 would have been better but I have only 6 weeks of M1 data. Here are the results, with 4 different basket-open times:
Profits are in pips. I included 0400 GMT (blue) because that was the default value (default BasketSendHour is 7, and I'm on a GMT+3 crim) and it turned out to be the best performer.
Interesting things to note:
* London and Sydney opens did about equally well. Both of them and NY started out losing in March, then LON & SYD took off in late March.
* NY open did pretty poorly, hitting about 55% wins, though it has made over 3000 pips in the last month!
* If you'd opened up a basket at LON, NY, and SYD opens, you'd have taken nearly a 5000-pip drawdown in March -- but you'd have made over 10000 pips since then!
* If you'd also added in the 0400 GMT basket, your DD would have been around 4000 pips, but you'd be up over 15000 pips since then! I want to test what it would look like if you opened a basket every hour... or better yet, what happens if you open a new basket as soon as the old one closes.
So Shelley looks pretty promising in this test. More importantly, this proof-of-concept shows that we can use Empty4 to backtest at least simple EAs.
I hesitate to post the tester just yet because, frankly, it's a mess. I tried to minimize the changes to the EA, isolating the "tester indicator" changes so it would be easy to apply them to other EAs, but it turned out not so easy. There are EA-specific things scattered throughout the code so I ended up making changes all over.
Other things to do:
* Clean up the code some
* Add jumping stops and a few other features
* Get a long history of M1 data on all symbols so it can accurately test more history
* Test different TP, SL, JSL values
* See what times of day perform the best
* Test open-a-basket-every-hour trading and continuous-basket trading
* Enhance the indicator to plot a single-page equity curve and some performance stats
* Extend the EA logic to test the "open pair X when its slope goes > 0.8, close it when it goes < 0.7" idea
* Test individual pairs and see if some pairs work significantly better or worse than others
Steve, if you see the value of this, I (and/or probably some of our other hard-core coders) would volunteer to design a set of library calls to provide the functions you're used to using -- looking at the current price, placing orders, querying orders, etc. Then you could call e.g. SHOrderSend instead of OrderSend, and the EA library would pass it on to OrderSend. But then you could just change an "#include <EALibrary.mqh>" line to "#include <TesterLibrary.mqh>", and shazam you can backtest your EA. I think that would be possible with minimal interference to your normal coding style.
That's the only way something like this is practical. It's a BIG job to convert one of your EAs to this testing approach, and by the time I get it working, you've probably already posted 3 new releases.
The "tester library" approach would also mean you could immediately see the long-term behavior of an EA as soon as you develop it, so you can tweak it if it doesn't do what you want. If you're willing to make this change, it will IMHO HUGELY increase the value of the EAs you develop, and save untold hours forward-testing EAs or parameter sets that ultimately don't work out very well. This changes the current "keyhole view" of EA performance to a broad landscape. I think you'd like the view.
