Open Price Modelling

New comment
 

Hello,

Sorry for asking one more question about Open Price, but my search in the forum didn't bring me a clear answer.

I added this line to the start() of my EA: 

if (High[0] != Low[0] || Volume[0] > 1) return;

The result, as expected, is that the backtesting is giving very close results on the three backtesting modes, and is also much, much faster on Control Points and Every Tick.

My question is: if I go live, will the behaviour of the EA be very different from what I get on the Every Tick backtesting ?

And if the answer is YES (as I saw it several times), then why ? What would make Live Ticks so different from extrapolated ones ?

Thanks !

 

First of all you compare doubles. It is better do it like this:

if ( MathAbs( High[0] - Low[0] ) > 0.00000001 || Volume[0] > 1 ) return;

Secondly, the reason is hidden not in type of ticks but I suppose in the latency and delays with response. If you use tester all the commands are executed immediately but when you go "live" you have to send the signal to the server and get the answer, which can take several seconds or even fail. Count on that when you develop your strategy.

 
hasayama:

First of all you compare doubles. It is better do it like this:

if ( MathAbs( High[0] - Low[0] ) > 0.00000001 || Volume[0] > 1 ) return;

Or use CompareDoubles() function from the standard library.


Secondly, the reason is hidden not in type of ticks but I suppose in the latency and delays with response. [...]

Not in this case. Volume[0]==1 does not necessarily happen in Live/Demo. This has been discussed many many times (for example: https://www.mql5.com/en/forum/125732). Please search for more info.
 

pindurs wrote >>

[...] What would make Live Ticks so different from extrapolated ones ?

Besides the obvious reason that live ticks are NOT interpolated, there are several differences (BTW - they are interpolated, not extrapolated):

  1. Each bar has exactly Volume[n] ticks in the Tester whereas in Live/Demo usually less than Volume[n] ticks actually arrive in each bar.
  2. In the Tester ticks are roughly evenly spread in the bar whereas in Live/Demo ticks are asynchronous and can arrive at any time in the bar.
  3. Time in the Tester is discrete (operations take zero time) whereas in Live/Demo ticks might be missed because start() has not finished it's previous run.
  4. Most of a tick's properties are static in the Tester (spread, swap, etc.) and it is only associated with a price change whereas in Live/Demo a tick is caused by any change in one of the market information identifiers.
 

Thanks for your answers,

I found this in another post, I suppose it will do the job:

if (LastTradeBarTime == Time[0]) return(0); // Not <first detected tick> on this bar so quit
else LastTradeBarTime = Time[0]; // and continue

I'm not sure to understand how this works works exactly, but if start() is firing only on opening bars, what do I care of differences between interpolated ticks and live ones ?

Don't you think that these differences are even more good reasons for not working with Every Tick modelling ?

I have the impression that an EA adapted for Open Prices would be more reliable in real conditions than one written and tested using Every Tick modelling.

Gordon, according to my understanding, your 3 first arguments are more against the use of Every Tick than Open price, and the 4th is neutral.

And what about the speed ? I know that the best way to improve speed is to code properly, but sometimes it helps to try complex and heavy things before to do the same job in a more simple way. I tried to use NonLagMA in one agent, the slowlyness of Every Tick backtesting was fa - sci - na - ting.

 
pindurs:

I found this in another post, I suppose it will do the job:

if (LastTradeBarTime == Time[0]) return(0); // Not <first detected tick> on this bar so quit
else LastTradeBarTime = Time[0]; // and continue

Yes. Don't forget to declare LastTradeBarTime as a local static variable or alternatively - on a global scope (IMHO, local static variable is better).


I'm not sure to understand how this works works exactly, but if start() is firing only on opening bars, what do I care of differences between interpolated ticks and live ones ?

start() fires every incoming tick, not only on opening bars. Your specific code makes start() return immediately on any tick that is not the 'first' tick of a bar, but that does not mean that your orders are not affected by the rest of the ticks in that bar. For example - an order's stops might be triggered during any tick... Regardless of the above code.


Don't you think that these differences are even more good reasons for not working with Every Tick modelling ?

I have the impression that an EA adapted for Open Prices would be more reliable in real conditions than one written and tested using Every Tick modelling.

Gordon, according to my understanding, your 3 first arguments are more against the use of Every Tick than Open price, and the 4th is neutral.

I am not sure a generalization can be made... But with the majority of EA's the 'Open Price' model will not be more reliable (see my explanation above).


And what about the speed ? I know that the best way to improve speed is to code properly, but sometimes it helps to try complex and heavy things before to do the same job in a more simple way. [...]

That's exactly why the developers added the other 2 models. When speed is more important than accuracy, use the other 2 models.
 

gordon wrote >>

start() fires every incoming tick, not only on opening bars. Your specific code makes start() return immediately on any tick that is not the 'first' tick of a bar, but that does not mean that your orders are not affected by the rest of the ticks in that bar.

Yes, sorry, it's what I mean't. The EA doesn't take any actions depending on intra-bar ticks.

For example - an order's stops might be triggered during any tick... Regardless of the above code.

Yes, but again, this is not depending on how the EA is filtering the ticks.

Sorry for insisting, but I'm still not able to see it differently. I believe that IF start() is filtering intra-bar ticks, then the behaviour of the agent is :

Open Price ≈ Control Points ≈ Every Tick ?≈ Live Ticks

There is a delay, you can't use anything depending on intra-bar ticks, etc. but this is since the beginning. The good side is that if it works, it should work live more or less the same way.

At the oposite, if the EA is using intra-bar Ticks, then it's behaviour is rather : Open Price ≠≠ Control Points ≠ Every Tick ?≠ Live Ticks

It's quite a constraint to work on Open Price only, but what if it makes backtesting more reliable AND forward testing more predictable ?

 
pindurs:

Sorry for insisting, but I'm still not able to see it differently. I believe that IF start() is filtering intra-bar ticks, then the behaviour of the agent is :

Open Price ≈ Control Points ≈ Every Tick ?≈ Live Ticks

There is a delay, you can't use anything depending on intra-bar ticks, etc. but this is since the beginning. The good side is that if it works, it should work live more or less the same way.

At the oposite, if the EA is using intra-bar Ticks, then it's behaviour is rather : Open Price ≠≠ Control Points ≠ Every Tick ?≠ Live Ticks

The point u r missing is that if u run the Tester on 'Open Prices' only, then stops for example can only exit at those prices. But that is almost certainly not the situation in Live. For example - EURUSD had an average of about ~45 ticks per M1 for the past week or so (I just did a quick check). Obviously these ticks are mostly inter-bar price movements which are different than O/C/H/L...

If we completely ignore these movements it means our stops will exit at completely abnormal price levels. How this affects the strategy depends on the specific strategy and is generally hard to asses. When we use the 'Every Tick' model on the other hand, then we are effectively setting those ~45 ticks into 45 price levels that pass through O/C/H/L. Is this accurate? Of course not! After all, the ticks are interpolated; we have no idea what the original prices were. But this is still likely to produce more accurate/reliable results for the majority of strategies (IMHO). There might be exceptions though.


[...] AND forward testing more predictable ?

That's a completely different subject. Whether or not back-test results predict future results is something often discussed in heated debates, one which I am not going to get into right now :)

 
Ok, I think I finally understood what you meant about the stops. Thank you !
 

Maybe one solution would be to have a large stoploss in the order ( for example at 3 deviation from the planned stoploss) and the planned stoploss would be hidden.

Like this, the order would be still stopped at the wanted price, and the EA would perform similarly on live ticks and Every Tick optimizing (but much faster) .

 
pindurs:

Maybe one solution would be to have a large stoploss in the order ( for example at 3 deviation from the planned stoploss) and the planned stoploss would be hidden.

I don't understand what u mean...? This wouldn't solve the problem and the result would be irrelevant to the original strategy.


[...] (but much faster) .

If your main concern is speed: (1) optimize the code as much as possible (2) if your computer is an antique consider upgrading. The Tester should fit your EA and not vice-versa. It makes no sense to design an EA around the Tester's limitations (IMHO). If this is really important to u then u r better off moving to another Testing platform (there are even some that use tick-level data).


p.s. Some good tips for code optimizing -> https://www.mql5.com/en/forum/123747.

New comment
Reason: