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

 
Slava:
You forgot to specify that the start of the measurement is at the beginning of the first OnTick. The end of measurement is at the beginning of OnDeinit.
Or at the beginning of OnTester, because
// После окончания бэктеста сначала вызывается OnTester, затем OnDeinit

Into the theme

Forum on trading, automated trading systems and trading strategies testing

Bugs, bugs, questions

fxsaber, 2016.08.25 11:13

Lifehack
// Возвращает true, если полностью выполнился OnTick() на последнее событие NewTick в тестере - окончание бэктеста. Иначе - false.
   static bool BACKTEST::IsEnding(void)
     {
      return(::TesterStatistics(STAT_BALANCEMIN) > 0);
     }
 
fxsaber:
Or at the beginning of the OnTester, since


And return the result of the measurement as the return code from OnTester
 
Slava:
And return the measurement result as a return code from OnTester

I haven't testedGetTickCount in the tester yet.I assumed that this function will be emulated by the tester, which in some situations may be logical.

By the way, how in the tester to understand the current time accurate to ms? With SymbolInfoTick+Tick.time_msc we can get the time of OnTick call of the main symbol. And so even check the correctness of slip mode of the tester. But there seems to be no other way.


Really, I wanted to ask about something else. In order to automate benches in optimizer with dropping first and last values, should we work through frames (to send OnTester-result), or it will distort the result?

 
GetTickCount in the tester works normally and is not emulated, unlike Sleep
 
fxsaber:

Really, I wanted to ask about something else. In order to automate the benches in the optimizer with discarding the first and last values, should I act through frames (to pass the OnTester-result), or will it distort the result?

It should not. It is sent after the measurement. Try
 
Slava:
Do not use a microsecond timer for mass measurements. Use regular millisecond GetTickCount.

GetMicrosecondCount slows down the tester more than GetTickCount (or emulated)?

Or did you mean not to use EventSetMillisecondTimer?

 
fxsaber:

Does GetMicrosecondCount slow down the tester more than GetTickCount (or is it emulated)?

Or do you mean the failure of EventSetMillisecondTimer?

I meant GetMicrosecondCount. You can't say for sure if it's slowing down the server. It may have an indirect effect. Therefore, it is better to use the system's native GetTickCount

GetMicrosecondCount is used to measure short code execution times. To measure the number of times OnTick was executed, it is better to use GetTickCount.

Try to use GetMicrosecondsCount instead of GetTickCount when you get stable results. You will tell me about it here. Maybe I'm worrying about it too much.

 
There are two current history tables, whose data are available through History-functions - Orders-table and Deals-table.

Their content can be influenced only through HistorySelect-functions. And it happens in the following way

  • The HistorySelect and HistorySelectByPosition - affect both tables simultaneously.
  • The HistoryDealSelect affects ONLY the Deals table (it has no effect on the current Orders-historical table).
  • HistoryOrderSelect affects ONLY the Orders table (does not affect the current Deals-history table).

 
It is possible to set Request.expiration field up to and including LONG_MAX + 2 in orders. Its value will be fully available through ORDER_TIME_EXPIRATION if the order is active (not in the history table).
 
The positionIdentifier of balance deals is equal to zero. Therefore it is easy to write, for example, this function
// Возвращает сумму всех балансовых не торговых операций (начисления + списания)
double GetSumBalanceOperations( void )
{
  double Res = 0;
  
  if (HistorySelectByPosition(0))
    for (int i = HistoryDealsTotal() - 1; i >= 0; i--)
      Res += HistoryDealGetDouble(HistoryDealGetTicket(i), DEAL_PROFIT);
      
  return(Res);
}

DEAL_ENTRY of such trades is equal to DEAL_ENTRY_IN (0).

Reason: