Libraries: OnTickMulti - page 3

New comment
 
Stanislav Korotky #:

There is no looking ahead, because if there are ticks for several symbols at time X, then alongside the first event on one of the instruments, the other symbols (for which events are still in the queue) will have the previous tick, not the next tick (as in the example, 00:04 came before 00:05, not after).

To ensure synchronisation, you need to implement it algorithmically in your code; for example, in the OnTick handler, you should query the tick times for all relevant symbols before initiating a trade. However, in principle, if the arbitrage is based specifically on ticks (rather than bars or minutes), it is difficult to envisage reliable synchronisation, because ticks for certain instruments may actually be absent for several seconds.

It’s all relative; for one instrument there will be a lag, whilst for another there will be a lead.

Everything fluctuates there; in the debugger, everything is synchronised, even with an almost empty OnTick function.

I have to convert bars into ticks for testing, to properly simulate the commission and spread.

I had to do this in OnTick so that the custom tester’s calculations matched those of MT4.

   int size=ArraySize(T);
   if(size==0) return;
   datetime dt1=(datetime)SymbolInfoInteger(name1,SYMBOL_TIME);
   datetime dt2=(datetime)SymbolInfoInteger(name2,SYMBOL_TIME);
   while(sh1<size && T[sh1]<dt1) sh1++;
   while(sh2<size && T[sh2]<dt2) sh2++;
   while(sh1<size && T[sh1]==dt1)
     {if(D1[sh1]>0)  Buy(name1);
      if(D1[sh1]<0) Sell(name1);
      if(D1[sh1]==0) Close(name1);
      sh1++;
     }
   while(sh2<size && T[sh2]==dt2)
     {if(D2[sh2]>0)  Buy(name2,D2[sh2]);
      if(D2[sh2]<0) Sell(name2,fabs(D2[sh2]));
      if(D2[sh2]==0) Close(name2);
      sh2++;
     }
 
Stanislav Korotky #:

To ensure synchronisation, you need to implement it algorithmically in your code; for example, in the OnTick handler, you should check the tick times for all relevant symbols before initiating a trade.

I’m afraid this won’t allow the OnTick handler to recognise that the sequence of ticks with the current time has ended. Most likely, only a millisecond OnTimer will help.

 
Rorschach #:

Everything is relative; for one instrument there will be a lag, whilst for another there will be a lead.

There is the current time (of the tester) – it is only in relation to this that the term ‘looking ahead’ can be used. If the current time is X, and for two instruments there are ticks corresponding to times X-1 and X-2 respectively, then these are the last known current ticks, and the algorithm must calculate using them. Now, if at time X-2 someone were to attempt to calculate the ticks for X-1 and X, that would constitute looking into the future. But technically, the tester does not allow this.
 
fxsaber #:

I’m afraid this won’t allow OnTick to recognise that the sequence of ticks with the current time has ended. Most likely, only a millisecond OnTimer will help.

It depends on how you write the time condition in the if statement – you need a strict >, not >=, and you mustn’t count the tick that triggered the condition. The same applies with a timer.
 
Stanislav Korotky #:
It depends on how you write the condition in the `if` statement based on time – you need a strict `>` rather than `>=`, and you mustn’t count the tick that triggered the condition.
I don’t understand.
 
Stanislav Korotky #:
It’ll work the same way with a timer.
It’s easier there.
 
fxsaber #:
I don’t understand.

Off the top of my head, with time identification accurate to the millisecond (the same applies to seconds):

// TODO: ArrayResize(lookback, <number-of-symbols>)
MqlTick lookback[];

void OnTickMulti(const string &symbol, const uint &index)
{
   static MqlTick t[1];
   static long timeCurrentMsc;
   
   SymbolInfoTick(symbol, t[0]);
   
   if(t[0].time_msc > timeCurrentMsc)
   {
      if(!timeCurrentMsc) // not quite the very beginning, so this is a new millisecond
      {
         // TODO: use the `lookback[] ticks` array for analysis and trades
         // they do not yet include the current tick, as it is from the next millisecond
         // ...
      }
      timeCurrentMsc = t[0].time_msc;
   }

   // Only after the analysis has been completed, update the registry with the new timestamp
   lookback[index] = t[0];
}

But I’ll say it again (for Rorschach’s sake) that synchronisation at such fine intervals is illusory. Ticks from a particular instrument may be absent for seconds at a time, in which case the price relevant to them may in fact become ‘out of date’. If it is important to someone that all prices are for the exact same [milli]second, then in the code snippet provided (in the commented-out analysis block), you need to additionally check that the tick times are equal, and only trade if this condition is met.

 
Stanislav Korotky #:

Off the top of my head, with time identification accurate to the millisecond (the same applies to seconds):

This method cannot guarantee that the ticks for all characters are up to date. This can only be achieved using a millisecond OnTimer.
 
fxsaber #:
This method cannot guarantee that the ticks for all instruments are up to date. This can only be achieved using a millisecond OnTimer.
What is meant by ‘up-to-date’ (this method returns the latest known ticks for all instruments; can CopyTicks be used if that is the issue)? And how would the OnTimer function produce a different result?
 

Stanislav Korotky #:
Что подразумевается под актуальностью (этот метод отдает последние известные тики по всем инструментам)?

There will be no more ticks with the last known time.

And how would OnTimer produce a different result?

A millisecond OnTimer guarantees that all ticks have elapsed BEFORE this timer event. In other words, the ticks are up to date for all symbols.

12345
New comment