Features of the mql5 language, subtleties and tricks - page 28

 

Forum on trading, automated trading systems and trading strategies testing

Bugs, bugs, questions

Renat Fatkhullin, 2017.03.31 09:10

Use ArraySize for dynamic objects and apply sizeof to static objects only. Sizeof counts at compile time and is always a constant.

 

Forum on trading, automated trading systems and testing trading strategies

SeriesInfoInteger(_Symbol,_Period,SERIES_SYNCHRONIZED)) and SymbolIsSynchronized(_Symbol)

Slawa, 2017.04.04 08:05

In Expert Advisors and scripts when calling Copy-functions several attempts are made - the first date on the server is checked, the first date in the client terminal is checked, compared to the requested date, the synchronization of the symbol is checked, a request is sent to download, a short wait and round from checking the synchronization. If the symbol is not synchronized, then gives what is and satisfies the conditions of the request. The synchronization of the requested timeseries is not checked, because it is completed on the fly when paging data.

In indicators only one request is done - no loop! Then everything they managed to take is given immediately.

 

In the MT5-tester in "real ticks" mode the basis of the history is not real ticks, but M1-bars. This means that if real ticks do not correspond to bars, they are ignored, and instead they are generated artificial ticks, which must correspond to bars.

At the same time, if CopyTicks is requested for more than 128K, then in the tester, they are taken not from the cache (real ticks + generated), and from the database - the real ones. And get a mismatch in the same tick history in the tester and what the tester was set.

 
fxsaber:

In the MT5-tester in "real ticks" mode the basis of the history is not real ticks, but M1-bars. This means that if real ticks do not correspond to bars, they are ignored, and instead they are generated artificial ticks, which must correspond to bars.

At the same time, if CopyTicks is requested for more than 128K, then in the tester, they are taken not from the cache (real ticks + generated), but from the database - the real ones. And get the mismatch in the tester between the history of ticks and what the tester has set up.

How awful! Is it really so? - Did you write it in SD?

What to believe now, how to live... (almost without sad irony)

 
Andrey Dik:

How awful! Is it really true? - In SD wrote?

This is a highly abbreviated retelling of the developers answers not my application to the SD.
 
fxsaber:

At the same time, if CopyTicks is requested for more than 128K edge pieces,

What edge ? 128K last or what ?

Or the first ?

 
George Merts:

What edge? 128K of the last?

Or the first ?


The most recent.
 
Andrey Dik:

How awful! Is it really true? - Did they write in the SD?

What to believe now, how to live... (almost without sad irony)

https://www.mql5.com/ru/docs/runtime/testing#real_ticks
 

In testing, minute data is considered more reliable.

Are minute bars more reliable? Isn't tick data the last resort? Why do you even need real tick data if it's not taken into account?

In my naivety, I used to do so: I tested it on minutes, then I tested it on ticks, then on real ticks as the final precision check. Now I understand that there is no sense in the third check.

 
Andrey Dik:

In testing, minute data is considered more reliable.

Are minute bars more reliable? Isn't tick data the last resort? Why do we even need real tick data if it is not taken into account?

Naively, I used to do this: I was testing on minutes, then I was testing on ticks, then I was testing on the real ticks as the final precision check. Now I understand that there is no sense in the third check.


There's no need to take the sentence out of context. The phrase sounds like this:

To ensure the greatest accuracy in testing, the minute bars are also used in the real tick mode. The tick data are checked and corrected by them. It also allows avoiding the divergence of charts in the tester and in the client terminal.

The tester checks the correspondence of tick data with parameters of the minute bar: a tick must not go beyond High/Low bar prices, the tick that opens and closes the minute must coincide with the Open/Close bar prices. The volume is also compared. If a mismatch is detected, all ticks corresponding to that minute bar are discarded. The generated ticks will be used instead (as in the "All ticks" mode).

If the history of the symbol contains a minute bar, but there is no tick data for that minute, the tester will generate ticks in the "All ticks" mode. This allows you to build a correct graph in the tester, in case of incomplete tick data at the broker.

If there is no minute bar in the symbol history, but there is tick data for that minute, they can be used in the tester. For example, bars of stock symbols are formed by Last prices. If only ticks with Bid/Ask prices arrive from the server, without Last prices, the bar will not be formed. The tester will use these tick data, as they do not contradict the minute data.

Tick data may not coincide with the minute bars for various reasons. For example, due to connection interruptions or other failures during data transmission from the source to the client terminal. The minute data is considered more reliable during testing.

As you can see, if you don't try to manipulate, it turns out that you misinterpreted the reference.
Reason: