Bug MQL5 quando si lavora con accesso alle serie temporali iClose/iOpen, ecc. - pagina 10

[Alain Verleyen]

fxsaber:

Sciocchezze.

+1

[Unicornis]

fxsaber:

Sciocchezze.

Finché "improvvisamente" (c) non si parla di prestazioni limitate del sistema (non importa quale).

[Farkhat Guzairov]

In questi giorni ho guardato più da vicino OnCalculate e la gestione dei dati di tick. Prima è stato scritto che tutto è fatto per evitare il "congelamento" degli indicatori scritti in modo errato, ma se vogliamo davvero elaborare l'intero flusso di dati in tick dalla precedente chiamata di OnCalculate, allora a un rapido movimento di prezzo (e rollback) dovremmo ottenere un array abbastanza "profondo", ci sono limitazioni sulla profondità dell'array di tick?

Non mi piacerebbe sentire una risposta come "OnCalculate riceverà un tick cumulativo..., per ottimizzare...".

Chi sta già analizzando i dati delle zecche, ha motivo di preoccuparsi?

[Unicornis]

Farkhat Guzairov:

In questi giorni ho dato un'occhiata a OnCalculate e all'elaborazione dei dati in tick. Prima è stato scritto che tutto è fatto per evitare il "congelamento" degli indicatori scritti in modo errato, ma se vogliamo davvero elaborare l'intero flusso di dati in tick dalla precedente chiamata di OnCalculate, allora a un rapido movimento di prezzo (e rollback) dovremmo ottenere un array abbastanza "profondo", ci sono limitazioni sulla profondità dell'array di tick?

Non mi piacerebbe sentire una risposta come "OnCalculate riceverà un tick cumulativo..., per ottimizzare...".

Chi sta già analizzando i dati delle zecche, ci sono ragioni per questi timori?

Nel 2008-2009 Renat una volta ha scritto che non c'è felicità nelle zecche, ha dato un esempio di un esperto. Le zecche vengono saltate comunque. Se ne hai bisogno, ottienihttps://www.mql5.com/ru/docs/series/copyticks su ogni chiamata, ma perderai comunque il 50/50 di top o bottom in cui vuoi entrare.

[Denis Kushnerik]

Faccio un salto qui per fare pubblicità. Sto cercando di capire perché ha smesso di funzionare da un mese a questa parte:

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");
///....
    }
} 

Aspettando la nuova uscita su Opening.

[Farkhat Guzairov]

Riprendi le domande relative all'ottimizzazione e al caricamento dei dati storici.

1. Il problema del corretto funzionamento delle funzioni iClose/iOpen, e in questo caso iTime, esiste e penso che non abbia senso aspettarsi che tutto sia perfetto. Forse dovrebbero essere semplicemente rimossi da MQL5 per evitare di rifare gli stessi errori? (Ho un problema, ma non ho tempo di descriverlo, perché ho trovato una soluzione, un altro "twist")

Forse c'è una soluzione, ma vorrei che fosse documentata e non un altro colpo di scena della comunità MQL5. Stiamo parlando di come gestire le richieste asincrone, che a loro volta sincronizzano i database locali per esempio:

Negli indicatori la funzione CopyTicks() restituisce il risultato immediatamente: Quando viene chiamato da un indicatore, CopyTick() restituisce immediatamente i tick disponibili per simbolo, e inizia anche a sincronizzare il database dei tick se non ci sono abbastanza dati. Tutti gli indicatori su un simbolo lavorano in un thread comune, quindi l'indicatore non ha diritto ad aspettare il completamento della sincronizzazione. Una volta completata la sincronizzazione, la successiva chiamata a CopyTicks() restituirà tutti i tick richiesti. La funzione OnCalculate() negli indicatori viene chiamata dopo ogni ricezione di tick.

La frase chiave è"Dopo aver finito la sincronizzazione, la prossima chiamata di CopyTicks() restituirà tutti i tick richiesti. "Signori, come fate a sapere quando la sincronizzazione è finita? È scritto come se prima della fine della sincronizzazione CopyTicks() restituisse per esempio -1, ma questo non è il caso. Come risultato, dopo alcuni ricarichi, il DB dell'indicatore si sincronizza e stiamo davvero ottenendo l'intero set di dati, ma se non ricarico l'indicatore non sto ottenendo questo set di dati, perché non so il risultato di finire questa dannata sincronizzazione.

Un esempio eclatante sono stati gli ultimi colpi, c'è stato un forte movimento su EURUSD, anche se l'indicatore è stato acceso tutto quel tempo e ha reso questo periodo normalmente, ma dopo averlo ricaricato (cambiato i parametri di input), l'indicatore ha iniziato a riflettere le informazioni in modo errato, rispettivamente sono state avviate ricerche di errori nell'indicatore (ricompilato e ricaricato più volte) ma niente ha aiutato, e poi è successo quel "miracolo", "Quandochiami CopyTick() da un indicatore, esso restituisce immediatamente i tick disponibili per il simbolo, e inizia anche la sincronizzazione della base di tick", forse dovresti creare (o avere) una funzione che possa dirci che al momento la sincronizzazione del database locale non è completata, questa funzione faciliterebbe il nostro compito e ci permetterebbe di scrivere un prodotto finale migliore per il mercato.

P.S.: La funzione SymbolInfoTick purtroppo non ha questa funzionalità.

[Farkhat Guzairov]

Purtroppo, questo esempio non funziona sempre:

//--- запросим тиковую историю с момента 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); 
        } 

Per essere precisi, funziona 1-2 volte su 10.

Ma nella situazione descritta sopra, non ha funzionato nemmeno una volta.

[Farkhat Guzairov]

Di nuovo una domanda, il database è aggiornato in tempo reale?

Come ho scritto sopra, per tutto il periodo che è stato problematico, l'indicatore ha funzionato, cioè la funzione CopyTicks() è stata chiamata regolarmente, ma a quanto pare non ha avuto alcun effetto sul database locale.... Questo è strano....

[Farkhat Guzairov]

Unicornis:

Nel 2008-2009, Renat ha scritto una volta che non c'è felicità nelle zecche, dando l'esempio di un esperto. Le zecche sono saltate così com'è. Se necessario, prendihttps://www.mql5.com/ru/docs/series/copyticks su ogni chiamata, ma perderai comunque il top/trough 50/50 in cui vuoi entrare.

Chi non lo fa, e chi ne ha bisogno :) per avere dati reali, in particolare le zecche.

[Rashid Umarov]

Farkhat Guzairov:

Riprendendo le domande relative all'ottimizzazione e al caricamento dei dati storici.

1. Il problema del corretto funzionamento delle funzioni iClose/iOpen, e in questo caso iTime, probabilmente esiste e non c'è motivo di aspettarsi che tutto sia perfetto. Forse possono essere semplicemente rimossi da MQL5 per evitare di ripetere gli stessi errori? (Ho un problema, ma non ho tempo di descriverlo, perché ho trovato una soluzione, un altro "colpo di scena")

Forse c'è una soluzione, ma vorrei che fosse documentata e non un altro colpo di scena della comunità MQL5. Stiamo parlando di come gestire le richieste asincrone, che a loro volta sincronizzano i database locali per esempio:

Negli indicatori la funzione CopyTicks() restituisce il risultato immediatamente: Quando viene chiamato da un indicatore, CopyTick() restituisce immediatamente i tick disponibili per simbolo, e inizia anche a sincronizzare il database dei tick se non ci sono abbastanza dati. Tutti gli indicatori su un simbolo lavorano in un thread comune, quindi l'indicatore non ha diritto ad aspettare il completamento della sincronizzazione. Una volta completata la sincronizzazione, la successiva chiamata a CopyTicks() restituirà tutti i tick richiesti. La funzione OnCalculate() negli indicatori viene chiamata dopo ogni tick in arrivo.

La frase chiave è"Dopo aver finito la sincronizzazione, la prossima chiamata di CopyTicks() restituirà tutti i tick richiesti. "Signori, come fate a sapere quando la sincronizzazione è finita? È scritto come se prima della fine della sincronizzazione CopyTicks() restituisse per esempio -1, ma questo non è il caso. Come risultato, dopo alcuni ricarichi, il DB dell'indicatore si sincronizza e stiamo davvero ottenendo l'intero set di dati, ma se non ricarico l'indicatore non sto ottenendo questo set di dati, perché non so il risultato di finire questa dannata sincronizzazione.

Un esempio eclatante sono stati gli ultimi colpi, c'è stato un forte movimento su EURUSD, anche se l'indicatore è stato acceso tutto quel tempo e ha reso questo periodo normalmente, ma dopo averlo ricaricato (cambiato i parametri di input), l'indicatore ha iniziato a riflettere le informazioni in modo errato, rispettivamente sono state avviate ricerche di errori nell'indicatore (ricompilato e ricaricato più volte) ma niente ha aiutato, e poi è successo quel "miracolo", "Quandochiami CopyTick() da un indicatore, esso restituisce immediatamente i tick disponibili per il simbolo, e inizia anche la sincronizzazione della base di tick", forse dovresti creare (o avere) una funzione che possa dirci che al momento la sincronizzazione del database locale non è completata, questa funzione faciliterebbe il nostro compito e ci permetterebbe di scrivere un prodotto finale migliore per il mercato.

P.S.: La funzione SymbolInfoTick purtroppo non ha questa funzionalità.

Cosa restituisce SERIES_SYNCHRONIZED in questi casi?