Home Indicatore tecnico Post

Monitoraggio del Calendario Economico e Cache per il Backtesting su MetaTrader 5

Allegato
53393.zip (32.58 KB, Scarica 0 volte)

Il Problema della Sincronizzazione del Calendario Economico

In breve: il calendario economico integrato di MetaTrader 5 non è (completamente) sincronizzato con le quotazioni storiche.

Le quotazioni sono contrassegnate con timestamp in base ai fusi orari in vigore sul server al momento della formazione di ciascuna barra corrispondente.

Una volta formate, le barre rimangono inalterate, compresi i loro timestamp. D'altra parte, il calendario economico fornisce informazioni sugli eventi (passati, presenti e futuri) legati al fuso orario attuale del server. Poiché molti broker seguono un programma di fuso orario specifico, comprese le modifiche per l'ora legale, i timestamp degli eventi storici possono essere spostati di 1 ora rispetto alle barre associate, per circa metà dell'anno.

Inoltre, i broker a volte cambiano i fusi orari in modo più radicale rispetto al semplice passaggio all'ora legale. Le quotazioni storiche possono apparire spostate di diverse ore a sinistra o a destra rispetto al momento degli eventi economici che si sono originariamente verificati, ma ora riportati dal calendario nel fuso orario aggiornato del server.

Tenendo conto che le notizie provengono da diversi paesi con i propri programmi di ora legale e che il tuo server può trovarsi in una regione con un altro programma, il tempo delle pubblicazioni delle notizie può "saltare" visivamente avanti e indietro nei grafici anche in modo più peculiare (per esempio, per alcune settimane in primavera e in autunno).

Perché è Importante il Backtesting con il Calendario Economico?

Tutto questo non sembra così importante online, ma cosa succede se vogliamo testare una strategia basata sulle notizie?

Sì, si può dire che il calendario non è supportato nel tester di MetaTrader nativamente, ma molti trader amano operare sulle notizie e tutti gli altri dovrebbero seguire le notizie per semplicemente allontanarsi dal mercato prima che impazzisca durante le pubblicazioni. Quindi il backtesting con il calendario è fondamentale. È per questo che è molto logico esportare il calendario in uno storage esterno (file, database) e poi importarlo nel tester. Uno degli strumenti di archiviazione per l'esperienza del calendario nel tester è stato presentato in questo libro di algotrading.

La Soluzione al Problema di Desincronizzazione

Ed ecco che ci imbattiamo nel problema della desincronizzazione delle quotazioni storiche con gli eventi storici. Per semplicità, questo problema è stato lasciato irrisolto nel libro.

Ora è risolto grazie alla versione estesa di CalendarCache.mqh e all'indicatore dimostrativo CalendarMonitorCachedTZ.mq5. Questo è solo una versione leggermente modificata di CalendarMonitorCached.mq5 dal libro.

L'indicatore monitora gli eventi economici e aggiorna dinamicamente una tabella sul grafico con diversi eventi passati e futuri.

Correzione del Tempo e Funzionalità Aggiuntive

Tutto il lavoro relativo alla correzione del tempo viene svolto dietro le quinte - nell'altra libreria pubblica TimeServerDST.mqh. Per comprendere meglio come funziona la correzione del tempo, si può utilizzare lo script CalendarCSVForDates.mq5 e confrontare file CSV con e senza correzioni affiancati.

Questo è come la libreria è incorporata nei codici sorgente di entrambi i programmi - lo script e questo indicatore.

#include <TimeServerDST.mqh> // includere prima della cache del calendario consente il supporto per la correzione del fuso orario
#include <MQL5Book/CalendarFilterCached.mqh>
#include <MQL5Book/CalendarCache.mqh>

Come nell'indicatore originale, c'è l'input string CalendarCacheFile, dove puoi fornire un nome del file di calendario per la scrittura o la lettura.

Quando l'indicatore è attaccato a un grafico online con un CalendarCacheFile vuoto, funziona con il calendario integrato al volo.

Quando l'indicatore è eseguito con un nome specifico in CalendarCacheFile e il file non esiste, l'indicatore esporta i record del calendario in un file di cache (crea il file) e termina. Questo è il momento in cui i timestamp devono/potranno essere corretti (vedi FixCachedTimesBySymbolHistory qui sotto).

Quando l'indicatore è eseguito con un nome di file di cache esistente in CalendarCacheFile, carica la cache e lavora con questa copia nello stesso modo in cui lavora con il calendario integrato. Questo è particolarmente utile per il tester.

Il Monitor del Calendario nel tester legge eventi dalla cache

Non dimenticare che il tester richiede di specificare file aggiuntivi, nel nostro caso - il file di calendario online preparato, nella direttiva #property tester_file O dovresti posizionare il file di calendario nella cartella comune C:/Users/<Utente>/AppData/Roaming/MetaQuotes/Terminal/Common/.

Naturalmente, la cache può essere caricata anche in un EA durante i backtest e le ottimizzazioni.

La stringa di input FixCachedTimesBySymbolHistory viene elaborata nel seguente modo.

Se è vuota, l'indicatore salva la cache senza correzioni di tempo.

Per abilitare le correzioni di tempo durante l'esportazione, devi specificare un simbolo, che verrà utilizzato per la rilevazione empirica dei fusi orari storici del server. Funziona in base alla storia delle quotazioni H1, preferibilmente "XAUUSD" o "EURUSD".

Grazie a questo input, solo un paio di righe sono state aggiunte nella nuova versione dell'indicatore:

         if(StringLen(FixCachedTimesBySymbolHistory))
            cache[].adjustTZonHistory(FixCachedTimesBySymbolHistory, true);

Il metodo adjustTZonHistory è stato specificamente introdotto nella classe CalendarCache per le regolazioni dei timestamp e la sua implementazione utilizza le funzionalità interne di TimeServerDST.mqh.

Il metodo deve essere chiamato online solo (non nel tester).

Normalmente il metodo dovrebbe essere chiamato su oggetti cache riempiti dal calendario integrato, subito dopo il riempimento. Altrimenti, se la cache è caricata da un file di calendario, o se il metodo è già stato chiamato prima, i contenuti della cache potrebbero già essere stati corretti. Allora applicherai una correzione su una correzione e otterrai timestamp errati.

Il secondo parametro (true) istruisce il metodo a scrivere i confini delle modifiche applicate nel log. Qualcosa del genere:

Correzione del tempo iniziata il 2021.07.19 00:30:00
2021.07.19 00:30:00: 148786 -10800 diff=-3600
2021.11.08 01:50:00: 135918 -7200 OK
2022.03.14 04:30:00: 161085 -10800 diff=-3600
2022.11.07 04:00:00: 165962 -7200 OK
2023.03.13 01:50:00: 168500 -10800 diff=-3600
2023.11.06 01:50:00: 169270 -7200 OK
2024.03.11 01:50:00: 181258 -10800 diff=-3600
2024.11.04 02:30:00: 208469 -7200 OK

Ogni riga contiene un tempo e un ID di un evento in cui è stata rilevata una nuova discrepanza, l'offset del tempo del server all'evento e quale differenza deve essere applicata a tutti i successivi timestamp per eliminare il bias nel tempo del server al momento della memorizzazione nella cache del calendario.

I file mqh allegati (CalendarFilter.mqh, CalendarCache.mqh, QuickSortStructT(Ref).mqh) contengono bugfix e miglioramenti rispetto alle loro versioni originali del libro.


Aggiornamenti

11.11.2024 - piccole correzioni e aggiornamenti in CalendarFilter.mqh, CalendarCache.mqh;

22.11.2024 - piccole correzioni e miglioramenti in CalendarCache.mqh.

Post correlati

Commento (0)