MQL5 bug when working with iClose/iOpen timeseries access, etc. - page 10

 
fxsaber:

Nonsense.

+1
 
fxsaber:

Nonsense.

As long as "suddenly" (c) there is no question of limited system performance (no matter which).

 

These days I've been looking more closely at OnCalculate and tick data handling. Earlier it was written that everything is done to avoid "freezing" of incorrectly written indicators, but if we really want to process the whole tick data flow since the previous call of OnCalculate, then at rapid price movement (and rollback) we should get a quite "deep" array, are there any limitations on the tick array depth?

I wouldn't like to hear an answer, such as "OnCalculate will receive an accumulating tick(s)..., to optimize...".

Who is already analyzing tick data, is there any reason for such concerns?

 
Farkhat Guzairov:

These days I've been looking more closely at OnCalculate and tick data handling. Earlier it was written that everything is done to avoid "freezing" of incorrectly written indicators, but if we really want to process the whole tick data flow since the previous call of OnCalculate, then at rapid price movement (and rollback) we should get a quite "deep" array, are there any limitations on the tick array depth?

I wouldn't like to hear an answer, such as "OnCalculate will receive an accumulating tick(s)..., to optimize...".

Who is already analyzing tick data, are there any reasons for such fears?

In 2008-2009 Renat once wrote that there is no happiness in ticks, he gave an example of an expert. Ticks are skipped anyway. If you need it, gethttps://www.mql5.com/ru/docs/series/copyticks on every call, but you will still miss the 50/50 top or bottom you want to enter.

Документация по MQL5: Доступ к таймсериям и индикаторам / CopyTicks
Документация по MQL5: Доступ к таймсериям и индикаторам / CopyTicks
  • www.mql5.com
[in]  Количество запрашиваемых тиков. Если параметры from и count не указаны, то в массив ticks_array[] будут записаны все доступные последние тики, но не более 2000. Первый вызов CopyTicks() инициирует синхронизацию базы тиков, хранящихся на жёстком диске по данному символу. Если тиков в локальной базе не хватает, то недостающие тики...
 

I'll just pop in here for the sake of publicity. I've been trying to figure out why this stopped working for a month now:

long lastbardaytime=0;

int OnInit(){ 
}

bool isNewBar(string symbol_,ENUM_TIMEFRAMES period_){
    long curbar = SeriesInfoInteger(symbol_,period_,SERIES_LASTBAR_DATE)%86400;
    if(lastbardaytime == 0){
        lastbardaytime = curbar;
    }
    if(lastbardaytime != curbar){
        lastbardaytime = curbar;
        return(true);
    }
    return(false);
}


void OnTick(){
    if(isNewBar(MIX-12.18,PERIOD_M1)){ 
        Print("New bar");
///....
    }
} 


Waiting for the new release on Opening.

 

Resuming questions related to optimisation and loading of historical data.

1. The problem of correct work of iClose/iOpen functions, and in this case iTime, exists and I think there is no sense to expect that everything will be perfect. Maybe they should be simply removed from MQL5 to avoid making the same mistakes again? (I have a problem, but I don't have time to describe it, because I have found a solution, another "twist")

Maybe there is a solution, but I would like it to be documented and not another MQL5 community twist. We are talking about how to deal with asynchronous requests, which in turn synchronize the local databases for example:

In indicators the CopyTicks() function returns the result immediately: When called from an indicator, CopyTick() will immediately return the available ticks per symbol, and will also start synchronising the tick database if there is not enough data. All indicators on one symbol work in one common thread, so the indicator has no right to wait for the completion of synchronization. Once the synchronisation is complete, the subsequent call to CopyTicks() will return all the requested ticks. The OnCalculate() function in indicators is called after each tick incoming.


The key phrase is"After finishing synchronisation the next call of CopyTicks() will return all requested tick s. ", gentlemen how do you know when synchronization is finished??? It is written as if before the end of the synchronization CopyTicks() returns for example -1, but this is not the case. As a result after a few reloads indicator DB synchronizes and we're really getting the whole dataset, but if I'm not reloading indicator I'm not getting this dataset, because I don't know result of finishing this damn synchronization.

A striking example were the last knocks, there was a sharp movement on EURUSD, though the indicator was on all that time and sort of rendered this period normally, but after I had reloaded it (changed input parameters), the indicator started to reflect information incorrectly, respectively searches for errors in indicator were started (recompiled and reloaded several times) but nothing helped, and then that "miracle" happened, "Whenyou call CopyTick() from an indicator, it will immediately return the ticks available for the symbol, and also starts synchronization of the ticks base", maybe you should create (or have) function that can tell us that at the moment the synchronization of the local database is not completed, this function would ease our task and would allow us to write a better quality product for the Market.

P.S.: The SymbolInfoTick function unfortunately doesn't have this functionality.

 

Unfortunately, this example does not always work:

//--- запросим тиковую историю с момента 1970.01.01 00:00.001 (параметр from=1 ms) 
      int received=CopyTicks(_Symbol,tick_array,COPY_TICKS_ALL,1,getticks); 
      if(received!=-1) 
        { 
         //--- выведем информацию о количестве тиков и затраченном времени времени 
         PrintFormat("%s: received %d ticks in %d ms",_Symbol,received,GetTickCount()-start); 
         //--- если тиковая история синхронизирована, то код ошибки равен нулю 
         if(GetLastError()==0) 
           { 
            success=true; 
            break; 
           } 
         else 
            PrintFormat("%s: Ticks are not synchronized yet, %d ticks received for %d ms. Error=%d", 
            _Symbol,received,GetTickCount()-start,_LastError); 
        } 

To be exact, it works 1-2 times out of 10 times.

But in the situation described above, it did not work even once.

 

Again a question, is the database updated in real time?

As I wrote above, the whole period that was problematic, the indicator worked, i.e. the CopyTicks() function was called regularly, but as it turns out it had no effect on the local database.... This is weird....

 
Unicornis:

In 2008-2009, Renat once wrote that there is no happiness in ticks, giving the example of an expert. The ticks are skipped as it is. If needed, gethttps://www.mql5.com/ru/docs/series/copyticks on every call, but you will still miss the 50/50 top/trough you want to enter.

Who doesn't, and who needs it :) to have actual data, in particular ticks.
 
Farkhat Guzairov:

Resuming questions related to optimisation and loading of historical data.

1. The problem with correct operation of iClose/iOpen functions, and in this case iTime, probably exists and there is no reason to expect that everything will be perfect. Perhaps they can be simply removed from MQL5 to avoid repeating the same mistakes? (I have a problem, but I don't have time to describe it, because I have found a solution, another "twist")

Maybe there is a solution, but I would like it to be documented and not another MQL5 community twist. We are talking about how to deal with asynchronous requests, which in turn synchronize the local databases for example:

In indicators the CopyTicks() function returns the result immediately: When called from an indicator, CopyTick() will immediately return the available ticks per symbol, and will also start synchronising the tick database if there is not enough data. All indicators on one symbol work in one common thread, so the indicator has no right to wait for the completion of synchronization. Once the synchronisation is complete, the subsequent call to CopyTicks() will return all the requested ticks. The OnCalculate() function in indicators is called after each tick incoming.


The key phrase is"After finishing synchronisation the next call of CopyTicks() will return all requested tick s. ", gentlemen how do you know when synchronization is finished??? It is written as if before the end of the synchronization CopyTicks() returns for example -1, but this is not the case. As a result after a few reloads indicator DB synchronizes and we're really getting the whole dataset, but if I'm not reloading indicator I'm not getting this dataset, because I don't know result of finishing this damn synchronization.

A striking example were the last knocks, there was a sharp movement on EURUSD, though the indicator was on all that time and sort of rendered this period normally, but after I had reloaded it (changed input parameters), the indicator started to reflect information incorrectly, respectively searches for errors in indicator were started (recompiled and reloaded several times) but nothing helped, and then that "miracle" happened, "Whenyou call CopyTick() from an indicator, it will immediately return the ticks available for the symbol, and also starts synchronization of the ticks base", maybe you should create (or have) function that can tell us that at the moment the synchronization of the local database is not completed, this function would ease our task and allow us to write a better end product for the Market.

P.S.: The SymbolInfoTick function unfortunately doesn't have this functionality.

What does SERIES_SYNCHRONIZED return in such cases?