Librerie: Calendario - pagina 2
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
In tutti i calendari HTML (compreso quello standard e in Terminal) la tripla (Attuale, Previsione, Precedente) = (Attuale, Previsione, Rivisto). Pertanto, non è possibile utilizzare il campo Rivisto nello storico finché non si verifica l'evento successivo corrispondente. Gli altri possono essere utilizzati.
Non ho lavorato con l'API del calendario locale - la sua documentazione lascia molto a desiderare (quindi sarebbe necessaria una libreria più logica). Non è possibile interrogare un array di modifiche agli eventi a partire dal change_id specificato? Per qualche motivo non è basato sul tempo. Purtroppo queste domande sono più per il calendario stesso e non per la libreria, ma dato che la libreria è sopra il calendario, rimangono aperte anche per esso. Il problema delle modifiche è che nella mia pratica passata di utilizzo di calendari esterni ho notato che alcuni campi possono essere modificati in modo retroattivo, per così dire, ed è per questo che abbiamo bisogno di testare tenendo conto della cronologia delle modifiche.
Non capisco come previous=revised(la struttura MqlCalendarValue ha tutti e 4 i campi: actual, prev, revised, forecast) e perché non si possa usare revised sulla cronologia - imho, revised può apparire (se previous è revised) in qualsiasi momento tra l'ultimo rilascio dell'evento e il successivo, cioè solo sulla cronologia.
Non ho lavorato con l'API del calendario locale - la sua documentazione lascia molto a desiderare (quindi sarebbe necessaria una libreria più logica). Non è possibile interrogare un array di modifiche agli eventi a partire dal change_id specificato? Per qualche motivo non è legato al tempo.
Ogni modifica nel calendario ha un proprio change_id. Quindi è possibile interrogare tutte le modifiche da un change_id specifico fino al change_id corrente.
Non capisco come previous=revised(la struttura MqlCalendarValue ha tutti e 4 i campi: actual, prev, revised, forecast) e perché non si possa usare revised sulla cronologia: imho, revised può apparire (se previous è revised) in qualsiasi momento tra l'ultimo rilascio dell'evento e il successivo, cioè solo sulla cronologia.
Nei calendari si possono vedere solo tre campi per un evento. Nell'API ce ne sono quattro. Revised è il valore di perfezionamento più recente, che può arrivare anche una settimana dopo la ricezione dell'Actual. Questo è il motivo del divieto, per certi versi logico, di utilizzare Revised nei backtest.
Vedo piuttosto limitati gli scenari di utilizzo del calendario. Se avete altre opzioni, fatele valere. Forse la libreria ha un'API che non è ottimale per i vostri scenari. Allora ci penseremo.
L'argomento sembra essere abbastanza nuovo.
Le funzioni GMT sono presenti, ma non sembrano essere utilizzate. Non so se siano necessarie.
Sono lasciate per il futuro. Poiché il calendario è legato all'ora del server e può essere preso dall'esterno.
Vedo in modo piuttosto limitato gli scenari di un uso conveniente del calendario. Se avete le vostre varianti, fatele valere. Forse la libreria ha un'API che non è ottimale per i vostri scenari. Allora ci penseremo.
L'argomento sembra essere abbastanza nuovo.
A giudicare dalla descrizione delle funzionalità del calendario di MT, dovremmo scrivere qualcosa come Observer con il monitoraggio di tutte le modifiche, l'arrivo di nuovi eventi per abbonamento e le modifiche in Actual, Revised.
Allora penso che potrebbe essere conveniente.
A giudicare dalla descrizione delle funzionalità del calendario MT, dovremmo scrivere qualcosa come Observer con il monitoraggio di tutte le modifiche e l'arrivo di nuovi eventi nell'abbonamento e le modifiche dei valori di Actual, Revised.
Terminologicamente non capisco.
Dal punto di vista terminologico, non capisco.
https://refactoring.guru/ru/design-patterns/observer
https://refactoring.guru/ru/design-patterns/observer
Grazie. Se stiamo parlando di OnCalendar, sarà una sorta di simulazione tramite il meccanismo change_id.
Naturalmente è meglio dimostrare gli scenari applicativi con un codice schematico.
Grazie. Se parliamo di OnCalendar, ci sarà una simulazione tramite il meccanismo change_id.
Stai parlando della simulazione degli eventi del calendario, che potrebbe essere introdotta in MT5 in futuro.
Mi riferivo al meccanismo di sottoscrizione degli eventi di interesse, compresa la modifica di Revised, che può cambiare in qualsiasi momento.
Se non conoscete il modello Observer, vi consiglio di studiare il link di Andrei.
L'essenza dell'idea è brevemente che, ad esempio:
Ho bisogno di conoscere tutti gli eventi EUR con importanza superiore a 3 per il trading. Mi rivolgo a un provider (un oggetto della classe che gestisce le sottoscrizioni e gli avvisi, chiamato anche publisher, può essere uno solo), mi iscrivo.
E poi il provider stesso monitora tutti i cambiamenti negli eventi che mi interessano e mi notifica (chiamando il metodo di elaborazione degli eventi con le informazioni corrispondenti).
Il succo dell'idea è brevemente che, ad esempio:
Ho bisogno di conoscere tutti gli eventi EUR di importanza superiore a 3 per il trading. Contatto un provider (oggetto della classe che gestisce le sottoscrizioni e gli avvisi, chiamato anche publisher, può essere singolo), sottoscrivo.
E poi il provider stesso monitora tutti i cambiamenti negli eventi che mi interessano e me lo notifica (chiamando il metodo di elaborazione degli eventi con le informazioni corrispondenti).
Nessun oggetto personalizzato può controllare se stesso senza una chiamata corrispondente. Cioè, deve essere scritto dall'utente nel suo codice. Se l'ha scritto, allora è lui stesso a elaborare il codice.
Il meccanismo change_id è molto semplice: si esegue il metodo Refresh. Dopo di che si ottengono i dati, cosa e dove è stato aggiornato nell'elenco degli eventi creati.