Bibliotheken: Kalender

Neuer Kommentar
 

Kalender:

Kalender - Fundamentalanalyse in Geschichte und Echtzeit.

Kalender

Author: fxsaber

 
Der Maestro hat sich der Stiftung angenommen. Bravo! Große Veränderungen stehen bevor :)
 
Aleksey Mavrin:
Der Maestro hat sich der Stiftung angenommen. Bravo! Große Veränderungen stehen an :)

Noch ist nichts in Sicht. Bibliotheken.

 
Bei der ersten Veröffentlichung wurde versehentlich Müll in den Quellcode eingefügt. Ich habe den Code aktualisiert.
 
Ich selbst benutze es als Erinnerung. 
#include <fxsaber\Calendar\Calendar.mqh> // https://www.mql5.com/de/code/32430

int OnInit()
{
  return(!EventSetTimer(1));
}

void OnTimer()
{
  CALENDAR Calendar;
  
  string Currencies[2];
  
  // Ermittelt die Währungen des aktuellen Zeichens.
  Currencies[0] = ::SymbolInfoString(_Symbol, SYMBOL_CURRENCY_BASE);
  Currencies[1] = ::SymbolInfoString(_Symbol, SYMBOL_CURRENCY_PROFIT);
    
  // Nimmt anstehende wichtige Ereignisse nach Symbolwährungen auf.
  Calendar.Set(Currencies);
  
  Comment(Calendar.ToString(0, 5, true)); // Sie wurden ausgedruckt.
}

Die Wahrscheinlichkeit, dass ich wichtige Nachrichten verpasse, ist deutlich geringer.


Ein solcher Beilaufruf von Null wird innerhalb von 0,6 ms ausgeführt. Natürlich ist es möglich, den Verbrauch auf Null zu reduzieren.

 

DerTerminkalender wird viel weiter in die Zukunft geschrieben. Daher können Sie auch im MT4 eine Erinnerung verwenden, indem Sie eine Datei aus MT5-Daten speichern (z. B. einen Monat im Voraus).

Dies ist, was ich für MT4 tun.

 
IMHO fehlt noch eine ausführlichere Dokumentation. Es ist klar, dass man in den Code schauen kann, aber dann kann man auch seinen eigenen Code schreiben, anstatt den Code anderer Leute zu analysieren ;-). Insbesondere ist nicht klar, ob man Get aufrufen kann, ohne vorher Set zu machen, und ob man den Filter zurücksetzen kann (soweit ich weiß, kann man das nicht). Aus den obigen Beispielen geht nicht klar hervor, ob es einen bequemeren Weg gibt, das Auftreten des Ereignisses zu verfolgen - insbesondere sollten wir, wenn ich es richtig verstanden habe, change_id und nicht das Auftreten von TimeCurrent vergleichen, weil die Datenaktualisierung nicht unbedingt genau mit dem Beginn des Ereignisses zusammenfällt.
 

Stanislav Korotky:
ИМХО, все же не хватает более подробной документации. Понятно, что можно заглянуть в код, но тогда вместо разбирания в чужом коде можно и свой написать ;-).

Drücken Sie innerhalb von mqh ALT+M. Die Namen der Methoden scheinen sinnvoll zu sein.

Insbesondere ist nicht klar, ob Get aufgerufen werden kann, ohne vorher Set zu machen, und ob man den Filter zurücksetzen kann (soweit ich weiß, kann man das nicht).

Set - füllt das Objekt mit Ereignissen. Der Zugriff darauf ist wie der Zugriff auf die Elemente eines Arrays.

Aus den obigen Beispielen geht nicht klar hervor, ob es einen bequemeren Weg gibt, das Auftreten des Ereignisses zu verfolgen - insbesondere, wenn ich es richtig verstanden habe, müssen Sie change_id vergleichen, nicht das Auftreten von TimeCurrent, weil die Datenaktualisierung nicht unbedingt genau mit dem Beginn des Ereignisses zusammenfällt.

Wenn es sich um einen Backtest handelt, gibt es keine change_id und kann es auch nicht geben.

Was die Echtzeit betrifft, so wird diese Funktionalität etwas später in der Bibliothek hinzugefügt.


Der Filter-Rollback ist derselbe wie überall sonst: Erstellen Sie eine Kopie des Objekts vor dem Filter.

 

Architektonisch ist es so gestaltet, dass es möglich ist, andere Datenquellen in Form von Parsern einzubinden. Zu diesem Zweck gibt es sogar ein EVENT::Source-Feld, das jetzt nur noch einem Wert "MetaTrader5" entspricht.

Es gibt also eine Funktionalität zum Stapeln von Kalendern. Angenommen, es werden Daten aus mehreren Quellen genommen und dann an einem Ort kombiniert.

 
fxsaber:

Wenn es sich um einen Backtest handelt, gibt es dort keine change_id und kann es auch nicht geben.

Dies ist eine fragwürdige Nuance: im wirklichen Leben können sich Ereignisse ändern, und wenn der Tester (über die Bibliothek) nicht die Geschichte der Änderungen reproduziert, fällt die Angemessenheit der Prüfung. Ein ähnliches Thema wurde hier bereits in einigen Threads angesprochen: Online-Indikatoren in einer Veranstaltung sind gleich, und dann werden sie korrigiert. Wenn wir mit den korrigierten Werten testen, werden wir nicht das Bild erhalten, das der Experte "on the fly" analysiert hat. Nun, oder ich habe die Situation mit dem Zugang zu den Updates falsch verstanden.

 
Stanislav Korotky:

Dies ist eine fragwürdige Nuance: Im wirklichen Leben können sich Ereignisse ändern, und wenn der Prüfer (über die Bibliothek) die Geschichte der Änderungen nicht reproduzieren kann, sinkt die Angemessenheit der Prüfung. Ein ähnliches Thema wurde hier bereits in einigen Threads angesprochen: Online-Indikatoren in einer Veranstaltung sind gleich, und dann werden sie korrigiert. Wenn wir mit den korrigierten Werten testen, erhalten wir nicht das Bild, das der Experte "on the fly" analysiert hat. Nun, oder ich habe die Situation mit dem Zugang zu den Updates falsch verstanden.

Der Kalender enthält vier Werte für jedes Ereignis:

  • Aktuell (Actual) - der erste Wert, der nach der Veröffentlichung der Nachricht eingegangen ist.
  • Prognostiziert - welcher Wert wurde (von wem?) vor der Veröffentlichung der Nachricht vorhergesagt.
  • Previous - der erste Wert, der nach der Veröffentlichung der gleichen Kalendernachricht beim letzten Mal empfangen wurde. D.h. er ist gleich dem Actual-Wert für das vorherige Mal: Previous[i] = Actual[i - 1].
  • Revidiert - der angepasste Wert des vorherigen Actual. Der Zeitpunkt (und die Anzahl der Male) dieser Aktualisierung wird nicht im Kalender gespeichert.

In allen HTML-Kalendern (einschließlich des Standardkalenders und des Terminals) ist das Tripel (Actual, Forecast, Previous) = (Actual, Forecast, Revised). Daher können Sie das Feld Überarbeitet im Verlauf nicht verwenden, bis das nächste relevante Ereignis eintritt. Die anderen Felder können verwendet werden.

Es gibt keine Informationen über den Verzögerungswert des Empfangs von Actual oder, genauer gesagt, über die Disynchronisierung eines bestimmten Handelsservers und der Nachrichtenquelle (und kann es auch nicht sein). Aus diesem Grund wird sie im Backtest nicht berücksichtigt. Diese Nuance ist klar.


In Anbetracht der obigen Ausführungen ist es völlig legitim, TimeTradeServer mit dem Zeitpunkt des Ereignisses im Backtest zu vergleichen. Und zwar mit Werten (Previous, Forecast,Revised) unmittelbar vor dem Ereignis, (Actual, Forecast,Previous) - unmittelbar danach.

123456789101112131415
Neuer Kommentar