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

 
fxsaber:

Probably meant that one pass can last longer than ~50 days

No, Slava got it right and said it.

 
Nikolai Semko:

The time density in the tester is completely different. It won't work.

I was wrong.
I was sure that theGetTickCount() function in the tester emulates values based on the test time.

It is very strange and illogical. Surprise for me. It means that GetTickCount() simply "freezes" in the tester.

 
Nikolai Semko:

I was wrong.
I was sure that the GetTickCount() function in the tester emulates values based on the test time.

Very strange and not logical. Surprise for me. I.e. it should be understood that GetTickCount() simply "freezes" in the tester.

Why is it illogical?

Within one call OnTick, OnCalculate, OnInit, OnDeinit etc is quite logical. Calculations can be very different in severity.

 
TheXpert:

No, Slava got it right and said it.

No, he didn't.
If exactly 50 days have passed since the start of the program, then the difference will show several hours.

But if you useGetMicrosecondCount() instead of GetTickCount(), then the time of not overflowing will be 584542 years instead of 50 days
ZY More exactly 583081 years if you consider the Gregorian calendar ))

 
Slava:

Why is it illogical?

Within one call OnTick, OnCalculate, OnInit, OnDeinit etc is quite logical. Calculations can be very different in severity.

Well yes, it's only logical for measuring the execution time of calculations of some function or block of code. For all the rest, such as measuring time between some events, functions GetTickCount() andGetMicrosecondCount() in the tester are useless.

 
After that, the origin of all the test grails is clear. ))
 
Nikolai Semko:

No, it is not.
If exactly 50 days have passed since the start of the program, the difference will show a few hours.

Such intervals are not measured

To be honest, even if such a case is taken into account, HOW to take it into account - I don't know.

 
TheXpert:

such intervals do not measure

And frankly speaking, even if such a case is taken into account, HOW to take it into account - I don't know. to attract another measurer? then maybe it is better not to use gettickcount at all.

No, of course you can not bother. 50 days - it really goes beyond the practical application. If you really need to test more than 50 days, better still useGetTickCount(), because it's easier, just with overflow control (will be additional variable).

 

In fact, the raised topic of local time in the tester is very toxic to fair competition. All white lies.
If I were MQ, I would close all these loopholes to determine the local time, because it is not needed in the tester, and it is only needed for noodling the ears of gullible newly minted traders.

Well, or at least remove this topic from this branch and others, if available.

 
Nikolai Semko:

In fact, raised the topic of local time in the tester is very toxic to fair competition. Everything is covered in white lies.
If I were MQ, I would close all these loopholes for determining the local time, because it is not needed in the Strategy Tester, and it is only needed to make false promises to credulous new traders.

Well, or at least remove this topic from this thread and from other threads, if available.

There is no deception in this thread. As for the practical application, I use it in KB. Convenient.

Reason: