Errors, bugs, questions - page 2437

 
Alexey Navoykov:

So OnTesterPass is called without frames present? Well then this is an obvious error. This event means receiving a frame, not the end of a pass.

All frames should arrive at OnTesterPass before the OnTesterDeinit event is called. This is normal healthy logic. Unless, again, we're talking about a forced test interruption.

OnTesterPass is called when at least one frame has arrived. It may come in a pack of frames. Therefore, OnTesterPass should accept frames in a loop, not one frame at a time. But if "after the last time - never", OnTesterPass is not called.

Optimization stops when the last result came. Frames can arrive later, especially if a large amount of data is passed in a frame, or if several frames are passed at once in one pass. Therefore, we need to arrange reception of the remaining frames in OnTesterDeinit, which is launched after the optimization is over - also in the loop.

This is a normal healthy logic.

I repeatedly gave examples of reception of frames exactly in OnTesterDeinit, not only in OnTesterPass. And it is reception of complex frames of different types

 
Slava:

if several frames are passed at once in one pass.

I tried this once, it didn't work. Only one FrameAdd worked.

 
Slava:

Optimisation stops when the last result has arrived. Frames may arrive later, especially if a large amount of data is transferred in a frame or if several frames are transferred at once in one pass. Therefore, it is necessary to arrange reception of the remaining frames in OnTesterDeinit, which is launched when optimization is over - also in the loop.

If frames can arrive later, there is no guarantee that they will also arrive at once in OnTesterDeinit? It means that we have to make a waiting loop, so how long should we wait?

I thought earlier that the situation is as follows: OnTesterPass is called only for those frames that arrived since the end of previous OnTesterPass, but if a new frame arrived while OnTesterPass was in progress, and specifically - since the last call of FrameNext and before completion of the function, this frame will hang, until a new frame generating the event arrives. This is why OnTesterDeinit is required to receive these dormant frames.

 
Alexey Navoykov:

If frames can arrive later, then there is no guarantee that they will be immediately available in OnTesterDeinit? I.e. you have to do a waiting cycle? And how long should you wait?

I thought earlier that the situation is as follows: OnTesterPass is called only for those frames that arrived since the end of previous OnTesterPass, but if a new frame arrives while OnTesterPass is in progress, and specifically - since the last call of FrameNext and before completion of the function, this frame will remain dangling, until a new frame generating the event arrives. This is why OnTesterDeinit is required to pick up these dormant frames.

FrameNext is a dumb mqd file read and nothing else.

FrameFirst is FileSeek.
 
fxsaber:

Tried this once, it didn't work. Only one FrameAdd worked.

I showed an example here.
 

Thank you.


PS FrameFirst is redundant here

Forum on trading, automated trading systems and strategy testing

Testing strategies on time schedule with autosubstitution of result to Expert Advisor

Slava, 2013.04.10 15:04

Here is an example. In OnTester, the Expert Advisor sends two frames - the history of deals and the history it was working on.

In OnTesterDeinit, it receives and processes all the frames of the first and the second type

void OnTesterDeinit()
  {
   string        name;
   ulong         pass;
   long          id;
   double        value;
   int           handle,i;
   BalanceInTime balance[];
   MqlRates      rates[];
//---
   FrameFirst();
   FrameFilter("",1);
   while(FrameNext(pass,name,id,value,balance))
     {
      handle=FileOpen(name+"_"+string(id)+"_"+IntegerToString(pass,5,'0')+".txt",FILE_WRITE|FILE_CSV|FILE_ANSI);
      if(handle!=INVALID_HANDLE)
        {
         for(i=0; i<ArraySize(balance); i++)
            FileWrite(handle,balance[i].date,EnumToString(balance[i].entry),DoubleToString(balance[i].price,5),DoubleToString(balance[i].balance,2));
         FileClose(handle);
        }
     }
//---
   FrameFirst();
   FrameFilter("",2);
   while(FrameNext(pass,name,id,value,rates))
     {
      handle=FileOpen(name+"_"+string(id)+"_"+IntegerToString(pass,5,'0')+".txt",FILE_WRITE|FILE_CSV|FILE_ANSI);
      if(handle!=INVALID_HANDLE)
        {
         for(i=0; i<ArraySize(rates); i++)
            FileWrite(handle,rates[i].time,DoubleToString(rates[i].open,5),DoubleToString(rates[i].high,5),DoubleToString(rates[i].low,5),DoubleToString(rates[i].close,5),string(rates[i].tick_volume));
         FileClose(handle);
        }
     }
//---
  }
 
fxsaber:


PS FrameFirst is superfluous here.

No. Not superfluous - purely methodologically. A complete block of code without any defaults

This code was ripped out of more complex code. Four different frame types were transmitted. At the same time we read OnTesterPass too. Here is the "refined" code.

 
Slava:

No. Not redundant - purely methodologically. A complete block of code without any defaults

This code was ripped out of more complex code. Four different frame types were transmitted. At the same time we read OnTesterPass as well. Here we present the "refined" code.

About FrameFirst is always superfluous if called before FrameFilter.

Wouldn't recommend transferring data through more than one frame.

 
fxsaber:

About FrameFirst is always redundant if called before FrameFilter.

Would not recommend passing data through more than one frame.

1. Yes. It can be superfluous.

2. one type of frames is read in OnTesterPass and finished in OnTesterDeinit. The other frames are read in OnTesterDeinit

This possibility to send and receive several types of frames allowed us to fix several errors that were difficult to reproduce in the tester. And the frames were transmitted only if there was a difference with some reference value.

 
Slava:

Will you open the opt-format?