garyfritz wrote:Yes, that's the kind of thing I'd like to be able to backtest. Unfortunately my situation right now means I can barely keep up with the forum posts, let alone do any coding or design. I don't know when I'm going to be able to get around to creating this indicator-backtester framework.

garyfritz wrote:I guess I never posted it, did I? Probably just as well, because it was an ad-hoc hack (an ad-hack?) as I figured out what I was doing. I'm not sure it's going to help you any, in fact I suspect it might confuse the issue more than it helps, but here 'tis.

garyfritz wrote:I'm not sure how applicable that ZigZag example is. It's a specialized tester written ground-up for ZZ. Some of the concepts will be similar but the general solution I have in mind (assuming we can actually make it work!!!) will be much more difficult.

garyfritz wrote:Here's my idea: we want this to work for any EA. The first thing I would do is to write a "wrapper" library that people would call instead of calling the MQL code directly. So instead of calling OrderSend() they would call BTOrderSend() or SHFOrderSend() or whatever. (Unfortunately I don't think MQL supports replacing the original OrderSend() with our own OrderSend() and still allowing us to access the original OrderSend().) So e.g. Steve would write his EAs as before, but calling functions with the BT (backtester) prefix.

garyfritz wrote:In the "wrapper" library, each BTxxx() function would just call the xxx() function. You would load in the "wrapper" library when you just wanted to run the EA normally.
Then the BackTester library would provide a different set of BTxxx() functions, but instead of calling the xxx() functions directly, it would perform the backtesting function.

garyfritz wrote:But actually....... now that I think through this a bit.....
The "wrapper" library and BTxxx() functions may not be necessary! Let's say you write your EA using the normal OrderSend() function. Everything works normally, and for the most part you don't have to do anything differently.
But the Backtester will run as an **indicator***, NOT an EA! You will copy your EA code into an indicator to test it. So it doesn't NEED to call EA functions like OrderSend(), and in fact it would probably be an error if it did. So the Backtester library will provide functions that replace the order functions used in an EA. Instead of re-calling the "real" OrderSend(), the backtester OrderSend() will record the details of the order. Then as the EA-turned-indicator executes, the Backtester will keep a list of all open orders and open positions, track any positions that open and close, and "do the right thing" as order prices are hit, etc. It will track the open and closed equity and probably chart it and/or dump it to a file for analysis.
Make sense so far? This approach has the huge advantage that it can be applied to ANY existing EA, with very little change to the EA source code. You'll probably have to make a few changes as you convert your EA into a backtester-indicator -- copy the EA source into an indicator, add some #include lines, add a BT_init() call in init(), add a BT_start() call in start(), things like that -- but that's a lot more straightforward than the "replace all xxx() calls by BTxxx()" approach that I envisioned originally.

garyfritz wrote:So ... if you want to start making progress on this, the first thing we need to do is to draw up a list of all the EA functions (and anything else) we'll need to replace. Anything that is EA-specific, anything that we'll need to re-implement to track orders & positions, etc. That will include all OrderXXX() and AccountXXX() functions... anything else?

garyfritz wrote:Then we'll need to start designing the logic behind them. That will be the tricky bit.

garyfritz wrote:Indicators execute very differently to EAs. EA start() gets called on every tick in realtime, and that's what the user's EA start() function will assume.
Indicator start() functions get called once per bar for history, and then once per tick in realtime, and also several recent bars may get re-called whenever it feels like it. That's messy and we don't want the backtester to work that way. We don't care about realtime updates of the chart, we're just interested in history.
I think the way to work this is that the backtester provides its own start() function, and then the user (when he converts his EA to a backtester-indicator) renames his start() to EA_start(). Then the backtester start() "simulates" the once-per-tick start() call of an EA by calling EA_start() for each bar.

garyfritz wrote:I don't know if there is any way to step through tick-by-tick history on, say, an H4 chart. Maybe we could do M1-level backtesting -- step through the M1 data in the chart and call EA_start() once for each minute, instead of once for each tick the way an actual realtime EA would execute.

garyfritz wrote:Hmm, problem. The EA is likely to refer to High, Low, Close, etc. In realtime EA execution, those refer to the current tick. How do we get them to refer to the H/L/C of the backtested M1 bar that we're calling EA_start() on?
Bigger problem: the EA will probably use iClose(), iHigh(), etc. The EA will expect those to be relative to realtime. I.e. shift=0 will refer to the currently-building bar. But when we're calling EA_start() on a historic M1 bar, shift=0 needs to refer to the current M1 bar. So I suspect the backtester will have to re-implement iClose() &etc. That's a problem because, unlike OrderSend() &etc, we still want to call the original iClose(). So we might have to implement wrapper functions for iClose() & similar, and EA writers will have to use (or convert when they use the backtester) BT_iClose(), BT_iOpen(), etc.
Ewww. And we'll have to do similar things for Time[], TimeCurrent(), and probably others. Ick. This is going to be messier than I hoped.

NeoTrader wrote:It's a nice Idea, but as I said above no function overloading of any kind in Empty4. This is also not possible in Indicators and in scripts...it just won't let you compile...

I also think that we should have a table (array) where all open/pending orders are stored that we can access through the library.
The Problem I see here is that within an indicator...also with a library that we call inside an indicator we have no access at all to the normal AccountXXX() functions and therefore need also to code the logic of this. This also means that we need Parameters to collect (accountsize, leverage,...)

garyfritz wrote:Hmm, problem. The EA is likely to refer to High, Low, Close, etc. In realtime EA execution, those refer to the current tick. How do we get them to refer to the H/L/C of the backtested M1 bar that we're calling EA_start() on?
Ewww. And we'll have to do similar things for Time[], TimeCurrent(), and probably others. Ick. This is going to be messier than I hoped.

That is really a Problem and would complicate things a lot.

Our goal as I understand it is to be able to test multi-currency and multi-timeframe strategies and to have a result if this strategy could/would be successful or not.

What about another way of doing this...
The rule sets of a strategy are most times not that complex...and could be transfered to an indicator with much less effort. Why not split the strategy in two pieces...

garyfritz wrote:So I guess we always need to use wrappers, which means the EA-writer will need to use BT_xxxx() functions for ALL EA functions. That's unfortunate, but not a fatal problem.

It would probably not be too hard to write a "backtester preprocessor" that accepts EA code and does the OrderXXX() -> BT_OrderXXX() &etc changes. That would make it easy for someone to use the backtester without any code changes for their EA. Steve wouldn't have to do anything different.

garyfritz wrote:Yes, we'd need tables to store orders, positions, etc. And yes, we'd have to simulate the AccountXXX() functions. We'd have to track the open & closed equity so the various AccountXXX() functions worked right.

garyfritz wrote:Well, it's still workable. If we require them to use BT_High, BT_Low, BT_iClose(), etc, it can still work. We just need to keep track of the current bar we're backtesting on, and have the iClose() "shift" variable based off that bar instead of bar 0. BT_High / BT_Time / etc would be relative to the current backtest bar instead of bar 0.

garyfritz wrote:Yes.

garyfritz wrote:That sounds like a very complex approach, and you're right we'd lose Steve. Plus I'm not convinced it would work for most EAs. The rules/logic in most EAs are spread throughout the EA code. I'm not confident the resulting split backtest EA would implement the same logic as the actual EA you want to trade.
I don't think it would be a simple matter to extract the EA logic. I think the entire EA has to be pasted into an indicator, with the BT_ library providing the appropriate behavior in the indicator environment.

Ok...then lets do it...where do we start...

NeoTrader wrote:No this is not a fatal Problem and also the "Preprocessor" should be not a great problem. How do you envision this? An external script (windows or MQL) that should be run on the EA to make a simple find and replace?

garyfritz wrote:Well, it's still workable. If we require them to use BT_High, BT_Low, BT_iClose(), etc, it can still work.

It is workable...thats true... we just could use a candle array where all the values of the current candle of the backtest loop are copied to and the BT_functions work only with this array...

Ok...then lets do it...where do we start...

Do you use any kind of Source control Tools? like Git or Subversion?

I don't know about your time but I would like to commit some time in this project because I really want/need some reliable testing and results that I can work with...And this is the one topic that bothers me most with Empty4...