Libraries: OnTickMulti - page 2

New comment
 

fxsaber #:

double OnTester()

{return AccountInfoDouble(ACCOUNT_BALANCE); }

What is this line for?

 
lynxntech #:

What is this line for?

To return the value of the required balance.

 

Have you checked to what extent the ticks in your solution are synchronised in time?

In standard testing, if you request ticks from different symbols, there is a lag of 1 tick between them. To check this, I created custom tests with ticks every minute.

 
Rorschach #:

Have you checked to what extent the ticks in your solution are synchronised in terms of time?

Everything is working correctly. It’s also working correctly in the standard Tester. If not, please show me.

 
fxsaber #:
It’s correct in the standard Tester. If not, please show me.

I’ve created custom ticks from the EUR and GBP one-minute charts (for convenience)

It’s correct for EUR, but for GBP it’s one tick early (check the time and price)

Files:
1.mq5  3 kb
 
Rorschach #:

I’ve created custom ticks based on the EUR and GBP minute charts (for convenience)

The EUR ones are correct; the GBP ones are one tick early (check the time and price)

Ticks with the same time do not arrive simultaneously. They all arrive sequentially. And if the EUR/USD tick with the later time arrived first, then at that moment nothing is known about the GBP/USD tick with the same time, which will arrive second. Therefore, at the moment the first EUR/USD tick arrives, the second GBP/USD tick simply does not exist; instead, the data from the previous GBP/USD tick is available.
 
fxsaber #:
Ticks with the same time stamp do not arrive simultaneously. They arrive sequentially. And if a tick for EUR/USD with an earlier time stamp arrives first, then at that moment nothing is known about the tick with the same time stamp for GBP/USD, which will arrive second. Therefore, when the first EURUSD tick arrives, the second GBPUSD tick simply does not exist; instead, there is data from the previous GBPUSD tick.

In the tester, this is a drawback; for arbitrage, synchronisation is required.

And not just for arbitrage. If a system is based on the correlation between instruments, then look-ahead bias arises

 
Rorschach #:

In the tester, this is a drawback; for arbitrage, synchronisation is required.

And not just for arbitrage. If the system is based on the correlation between instruments, then forward-looking behaviour arises

For such cases, there is an execution delay that can be configured in the Tester.
 
fxsaber #:
For such cases, there is an execution delay that can be configured in the Tester.
It turned out to be a bit tricky for me. In the init function, I used a custom tester to read the inputs and store them in an array; then, in the OnTick function of the tester, I read the inputs and synchronised them
 
Rorschach #:

In the tester, this is a drawback; for arbitrage, synchronisation is required.

And not just for arbitrage. If the system is based on the correlation between instruments, then there is a risk of looking into the future

There is no look-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 check 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 symbols may actually be absent for several seconds.

12345
New comment