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

[Unicornis]

Vitaly Muzichenko:

Quindi, sarà possibile avere un indicatore molto veloce con tale costruzione?

Più probabilmente, OnCalculate non sarà chiamato su ogni tick, ma dopo un pacchetto di tick.

Se è così, questa è una grande notizia!

[fxsaber]

Renat Fatkhullin:

Abbiamo un'idea per gli indicatori che non contengono il flag #property tester_everytick_calculate, per includere la modalità di calcolo sulla base dell'accettazione del pacchetto di tick, invece che su ogni tick.

Questo risolverà radicalmente il problema degli indicatori in ritardo, conservando la possibilità di garantire l'elaborazione di ogni tick per alcuni indicatori.

Propongo un'altra soluzione.

SymbolInfoTick

Restituisce i prezzi correnti di un simbolo specificato in una variabile di tipo MqlTick.

bool  SymbolInfoTick( 
   string    symbol,     // символ 
   MqlTick&  tick        // ссылка на структуру
   bool      IndicatorMode = true; // индикаторный или реальный (текущий) тик
   );

Parametri

simbolo

[Nome del simbolo.

tick .

[out] Una struttura di riferimento di tipoMqlTick, i prezzi correnti e il tempo di aggiornamento dell'ultimo prezzo sono inseriti in essa.

IndicatorMode

[out] true - negli indicatori restituisce il tick che ha innescato il NewCalculate corrente, false - tick corrente (tempo reale) di un simbolo.

Valore restituito

Restituisce true se ha successo, altrimenti false.

Allora in OnCalculate sarà sufficiente scrivere solo questo costrutto

// Возвращает true, если текущий и индикаторный тики совпадают
bool IsRealTick( void )
{
  MqlTick Tick1, Tick2;
  
  return(SymbolInfoTick(_Symbol, Tick1) && SymbolInfoTick(_Symbol, Tick2, false) && (Tick1.time_msc == Time2.time_msc));
}

int OnCalculate( ... )
{
  if (prev_calculated && !IsRealTick())
    return(prev_calculated); // Если тик устарел, идем к следующему
    
  // Body
  
  return(rates_total);
}

Questa soluzione sarebbe più flessibile e conveniente da usare e implementare.

SZY Sarebbe meglio avere la numerazione dei tick, con la possibilità di ottenere il numero di tick attuali e dell'indicatore. Ma questa variante è più difficile per gli sviluppatori. Quindi, probabilmente, non è necessario.

[fxsaber]

fxsaber:

Suggerisco un'altra soluzione.

Se non viene fatto nulla dagli sviluppatori (che è un'ottima opzione, tra l'altro), è ancora possibile bypassare tutti i freni in questo modo

int OnCalculate( ... )
{
  static ulong MinTimeMsc = 0
  const ulong StartTime = GetMicrosecondCount();
  
  MqlTick Tick;
  const bool Res = prev_calculated && SymbolInfoTick(_Symbol, Tick);
  
  if (Res && (Tick.timeMsc < MinTimeMsc))
    return(prev_calculated); // Если тик устарел, идем к следующему
    
  // Body
  
  if (Res)
    MinTimeMsc = Tick.time_msc + (GetMicrosecondCount - StartTime) / 2000;
  
  return(rates_total);
}

[Unicornis]

fxsaber:

Se gli sviluppatori non fanno nulla (che è un'ottima opzione, tra l'altro), è possibile bypassare tutti i freni ora in questo modo

Beh, non abbiamo bisogno di zecche nel mezzo di una barra, sono forzatamente saltate comunque. Aspettiamo l'implementazione da parte di mql.

[fxsaber]

Unicornis:

Beh, non abbiamo bisogno di zecche nel mezzo di una barra, sono forzatamente saltate comunque. Aspettiamo l'implementazione di mql.

Onestamente, non capisco, cosa ha impedito ai malati di scrivere da soli una soluzione al loro problema?

E perché gli sviluppatori dovrebbero cambiare qualcosa qui?

La soluzione può essere implementata come un file mqh e collegata a qualsiasi indicatore, come è implementato in Init_Sync. Ma richiede un sacco di codice che non è molto ovvio. E qui è solo poche righe.

[Farkhat Guzairov]

Renat Fatkhullin:

L'aggiornamento congelato del lasso di tempo invisibile di qualcun altro dopo la comunicazione di riconnessione è stato sistemato e risolto. Il motivo era lo stato della cache non corretto dopo la riconnessione.

La versione beta 1946 è disponibile tramite Help -> Check Desktop Updates -> Latest Beta Version.

Rinat, 3 giorni di test senza problemi, grazie!

[Unicornis]

fxsaber:

Onestamente, non capisco cosa abbia impedito ai malati di scrivere da soli una soluzione al loro problema?

E perché gli sviluppatori dovrebbero cambiare qualcosa qui?

Chi soffre non può cambiare in alcun modo il numero di tick in arrivo nell'indicatore, li salta nell'indicatore fino a una nuova barra, se l'indicatore conta per un lungo periodo, i tick vengono saltati comunque. In qualche modo dobbiamo adattarci alla realtà.

Se per un simbolo il valore di picco è di ~800 tick al minuto, allora per il sintetico di diversi simboli già 2300 tick al minuto. L'apertura di un sintetico e di un simbolo da esso raggiunge un picco di ~3000 tick al minuto. Aggiungi un altro timeframe dello stesso sintetico e lo stesso simbolo, e otteniamo... Ok, gli schermi di Elder erano tre, otteniamo ~9000 tick al minuto o 150 tick al secondo. Rinat ha già scritto sui problemi di performance. Perché passare 150 tick al secondo attraverso un indicatore multisimbolo-mtf quando hai bisogno di 1-n tick al minuto per tutti i simboli tf? Allo stesso modo, i vantaggi di ospitare mql includono nessun overhead dal sistema host, il terminale è lo stesso host solo per gli indicatori e EAs. Se il calcolo dell'indicatore consiste in RSI(3) + EMA(5) + EMA(7), allora naturalmente nessun problema nei prossimi 10 anni.

Nel sintetico (in realtà è un indicatore multisimbolo del terminale) gli sviluppatori in qualche modo hanno avuto l'idea di incollare alcuni simboli, perché dovremmo duplicare gli elementi di questo sistema (supponiamo che non sia nemmeno perfetto) a livello di artigianato del programmatore nell'indicatore? Se il sistema può essere semplificato, perché non farlo? Quando la Terra stava ancora su tre elefanti, hanno inventato il tempo di 5 secondi per una ragione.

Upd. Si può introdurre il timeframe 5 secondi senza storia e i tick saranno solo una volta in 5 secondi, e per testare tutti i tipi di soluzioni (compilando un indicatore con qualche prefisso per lavorare solo su 5S, altri indicatori non funzioneranno su di esso) - l'ideologia esistente del terminale non cambierà, quindi possiamo cambiare e modificare le soluzioni, e la soluzione migliore / ottimale si formerà durante il test.

(LMS alle vostre librerie di sviluppo, sintetici, finestre staccate, ecc. Sviluppatori).

[fxsaber]

Unicornis:

Anche se ci sono un milione di tic al minuto, questo non rende la soluzione impraticabile.

[Unicornis]

fxsaber:

Un milione di tic al minuto non rende la soluzione impraticabile.

La questione non riguarda la praticabilità della soluzione. La ragionevolezza di chiamare l'indicatore ad ogni tick raggiunto prima del quale si è perso un numero sconosciuto di tick, inoltre, si considera una certa obsolescenza di un tick? Se qualcosa viene saltato (con l'aumento del carico) e non conosciamo la rilevanza della spunta, allora questa situazione non risolve il problema analitico - se no, perché preoccuparsene. In generale, vietate il flusso di tick negli indicatori, lasciate i tick all'indicatore dalla piattaforma una volta ogni 5 secondi - 12 tick al minuto, è sufficiente.

[fxsaber]

Unicornis:

La questione non riguarda la praticabilità della soluzione. La ragionevolezza di chiamare l'indicatore ad ogni tick raggiunto prima del quale si è perso un numero sconosciuto di tick, oltre ad una certa obsolescenza di un tick, è considerata come un'idea. Se qualcosa viene saltato (con l'aumento del carico) e non conosciamo la rilevanza della spunta, allora questa situazione non risolve il problema analitico - se no, perché preoccuparsene. In generale, il flusso di tick negli indicatori dovrebbe essere vietato, i tick provenienti dalla piattaforma ogni 5 secondi dovrebbero essere lasciati - 12 tick al minuto, è sufficiente.

Stupidità.