Bibliothèque: Calendrier

Nouveau commentaire
 

Calendrier:

Calendrier - analyse fondamentale sur l'historique et en temps réel.

Calendrier

Author: fxsaber

 
Le maestro s'est attaqué à la fondation. Bravo ! De grands changements sont à venir :)
 
Aleksey Mavrin:
Le maestro s'est attaqué à la fondation. Bravo ! De grands changements sont à venir :)

Rien n'est encore prévu. Bibliothèques.

 
Lors de la publication initiale, le code source a été accidentellement truffé de déchets. Mise à jour du code.
 
Pour ma part, je m'en sers comme d'un pense-bête. 
#include <fxsaber\Calendar\Calendar.mqh> // https://www.mql5.com/fr/code/32430

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

void OnTimer()
{
  CALENDAR Calendar;
  
  string Currencies[2];
  
  // Obtenir les devises du caractère courant.
  Currencies[0] = ::SymbolInfoString(_Symbol, SYMBOL_CURRENCY_BASE);
  Currencies[1] = ::SymbolInfoString(_Symbol, SYMBOL_CURRENCY_PROFIT);
    
  // Accroche les événements importants à venir par symbole devises.
  Calendar.Set(Currencies);
  
  Comment(Calendar.ToString(0, 5, true)); // Les a imprimées.
}

La probabilité de manquer une nouvelle importante est considérablement réduite.


Un tel appel à la hache à partir de zéro est exécuté en 0,6 ms. Bien entendu, il est possible de réduire la consommation à zéro.

 

Lecalendrier des événements est écrit beaucoup plus loin dans l'avenir. Par conséquent, vous pouvez également utiliser un rappel dans MT4 en enregistrant un fichier à partir des données de MT5 (un mois à l'avance, par exemple).

C'est ce que je fais pour MT4.

 
Selon moi, il manque encore une documentation plus détaillée. Il est clair que vous pouvez regarder dans le code, mais alors vous pouvez écrire votre propre code au lieu d'analyser le code d'autres personnes ;-). En particulier, il n'est pas clair si l'on peut appeler Get sans faire Set au préalable, et si l'on peut annuler le filtre (d'après ce que j'ai compris, ce n'est pas possible). Les exemples ci-dessus n'indiquent pas clairement s'il existe un moyen plus pratique de suivre l'occurrence de l'événement - en particulier, si j'ai bien compris, nous devrions comparer change_id, et non l'occurrence de TimeCurrent, parce que la mise à jour des données ne coïncide pas nécessairement avec le début de l'événement.
 

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

Dans mqh, appuyez sur ALT+M. Les noms des méthodes semblent avoir un sens.

En particulier, il n'est pas clair si Get peut être appelé sans avoir d'abord fait Set, et si vous pouvez annuler le filtre (d'après ce que j'ai compris, ce n'est pas le cas).

Set - remplit l'objet d'événements. L'accès à ces événements est similaire à l'accès aux éléments d'un tableau.

D'après les exemples ci-dessus, il n'est pas certain qu'il existe un moyen plus pratique de suivre l'occurrence de l'événement - en particulier, si j'ai bien compris, vous devez comparer change_id, et non l'occurrence de TimeCurrent, car la mise à jour des données ne coïncide pas nécessairement avec le début de l'événement.

Si nous parlons de backtest, il n'y a pas et il ne peut pas y avoir de change_id.

En ce qui concerne le temps réel, cette fonctionnalité sera ajoutée un peu plus tard dans la bibliothèque.


Le retour en arrière du filtre est le même que partout ailleurs : faire une copie de l'objet avant le filtre.

 

Sur le plan architectural, il est possible d'intégrer d'autres sources de données sous la forme d'analyseurs. Il existe même un champ EVENT::Source à cet effet, qui est désormais égal à une seule valeur "MetaTrader5".

Il existe donc une fonctionnalité permettant d'empiler les calendriers. Nous avons supposé qu'il prenait des données de plusieurs sources et qu'il les combinait en un seul endroit.

 
fxsaber:

Si nous parlons de backtest, il n'y a pas de change_id et il ne peut pas y en avoir.

Il s'agit d'une nuance discutable : dans la vie réelle, les événements peuvent changer, et si le testeur (via la bibliothèque) ne reproduit pas l'historique des changements, l'adéquation du test est compromise. Un sujet similaire a déjà été abordé ici dans certains fils de discussion : les indicateurs en ligne d'un événement sont les mêmes, puis ils sont corrigés. Si nous testons en utilisant les valeurs corrigées, nous n'obtiendrons pas l'image que l'expert a analysée "à la volée". Ou alors j'ai mal compris la situation en ce qui concerne l'accès aux mises à jour.

 
Stanislav Korotky:

Il s'agit d'une nuance discutable : dans la vie réelle, les événements peuvent changer, et si le testeur (via la bibliothèque) ne reproduit pas l'historique des changements, l'adéquation des tests diminue. Un sujet similaire a déjà été abordé ici dans certains fils de discussion : les indicateurs en ligne d'un événement sont les mêmes, puis ils sont corrigés. Si nous testons en utilisant les valeurs corrigées, nous n'obtiendrons pas l'image que l'expert a analysée "à la volée". Ou alors j'ai mal compris la situation en ce qui concerne l'accès aux mises à jour.

Le calendrier contient quatre valeurs pour chaque événement :

  • Current (Actual) - la première valeur reçue après le communiqué de presse.
  • Prévision - valeur prédite (par qui ?) avant la publication de la nouvelle.
  • Précédent - valeur reçue en premier après la publication de la même nouvelle dans le calendrier la fois précédente. En d'autres termes, elle est égale à la valeur réelle pour la période précédente : Précédent[i] = Réel[i - 1].
  • Révisé - la valeur ajustée de l'actualité précédente. L'heure (et le nombre de fois) de cette mise à jour n'est pas enregistrée dans le calendrier.

Dans tous les calendriers HTML (y compris le calendrier standard et dans Terminal), le triple (Réel, Prévision, Précédent) = (Réel, Prévision, Révisé). Par conséquent, vous ne pouvez pas utiliser le champ Révisé dans l'historique jusqu'à ce que le prochain événement pertinent se produise. Les autres peuvent être utilisés.

Il n'y a pas (et il ne peut pas y avoir) d'informations sur la valeur de décalage de la réception de Actual, ou, plus précisément, sur la désynchronisation d'un serveur de négociation particulier et de la source d'informations. C'est pourquoi elle n'est pas prise en compte dans le backtest. Cette nuance est claire.


Compte tenu de ce qui précède, il est tout à fait légitime de comparer TimeTradeServer avec l'heure de l'événement dans le backtest. Et d'utiliser les valeurs (Précédent, Prévu,Révisé) juste avant l'événement, (Actuel, Prévu,Précédent) - juste après.

123456789101112131415
Nouveau commentaire