Discussion de l'article "Le prototype du robot de trading" - page 2

[Alexey Klenov]

Je recommande d'éviter cette conception

//------------------------------------------------------------------ CheckNewBar
bool CExpertAdvisor::CheckNewBar()          // fonction de vérification de l'apparition d'une nouvelle barre
  {
   MqlRates rt[2];
   if(CopyRates(m_smb,m_tf,0,2,rt)!=2)      // copier les barres
     { Print("CopyRates of ",m_smb," failed, no history"); return(false); }
   if(rt[1].tick_volume>1) return(false);   // vérifier le volume 
   return(true);
  }

car le traitement du tick précédent peut prendre suffisamment de temps pour manquer l'arrivée du premier tick de la nouvelle barre.

respectivement, il est possible de manquer l'ouverture.

Il est préférable de se lier à l'heure d'ouverture de la barre, mais pour cela, vous devez sauvegarder l'heure précédente de la barre zéro, par exemple, pour la comparer à l'heure actuelle de la barre zéro.

Si c'est la même chose, il n'y a pas de nouvelle barre

Si c'est différent, alors au moins une nouvelle (prochaine) barre est ouverte, après quoi nous initialisons l'heure mémorisée de la barre zéro avec l'heure actuelle de la barre zéro.

Cette construction est plus fiable.

[Maximillion Propheet]

Cette question sera abordée dans un prochain article :

• des ordres stop-loss et take-profit *robustes* (c'est-à-dire côté serveur) par transaction à différents niveaux ; ces ordres sont *nécessaires* pour éviter les problèmes liés aux pannes du réseau et du programme client (déconnexions prolongées du réseau, dérapage induit par le lag du réseau (et requotes), abandon du programme client ou du système d'exploitation, redémarrages, plantages (absence prolongée du logiciel côté client), etc) ; les ordres dits "virtuels" ne suffisent pas, pas plus que les substituts non OCO (non, ce n'est *pas* négociable, si la robustesse est une exigence, les ordres stop-loss et take-profit *doivent* être côté serveur, et si l'un est touché, l'autre *doit* être supprimé *par le serveur* en même temps).
  

• récupération *robuste* de l'état de chaque transaction en cas de panne ; en d'autres termes, si le client/OS tombe en panne (et redémarre automatiquement), je veux que l'EA sache exactement ce qui s'est passé avec les transactions et les ordres individuels en cours dans l'intervalle : rempli, fermé, toujours actif, quels ordres s/l et t/p associés appartiennent à quelle transaction/ordre, etc. (non, écrire l'état sur le disque *n'est pas* suffisant car il y a une condition de course entre l'ouverture d'une transaction et l'écriture de l'état sur le disque et le programme client peut se planter exactement au moment inapproprié ; les commentaires d'ordre côté serveur pourraient le faire, *si* ils étaient modifiables).
  

Pour autant que je sache, MT5 ne supporte que *1* (un) ordre s/l et t/p côté serveur *par instrument* (pas par transaction) et pas d'ordres OCO (les ordres OCO peuvent être utilisés pour simuler des ordres s/l et t/p par transaction, mais il y a là aussi une condition de course). A moins que les problèmes ci-dessus ne soient résolus, je ne m'engagerais pas pour plus de 100 $ dans le trading via MT5 (EAs simplistes à un seul ordre et à une seule période de temps, dans une seule direction, de type MA cross). Et je ne suis même pas sûr des 100 $.

[Дмитрий Александрович]

olyakish:

Je recommande d'éviter cette conception

car le traitement du tick précédent peut prendre suffisamment de temps pour manquer l'arrivée du premier tick de la nouvelle barre.

respectivement, il est possible de manquer l'ouverture.

Il est préférable de se lier à l'heure d'ouverture de la barre, mais pour cela vous devez sauvegarder l'heure précédente de la barre zéro, par exemple, pour la comparer à l'heure actuelle de la barre zéro.

Si c'est la même chose, il n'y a pas de nouvelle barre.

Si c'est différent, au moins une nouvelle (prochaine) barre est ouverte, après quoi nous initialisons l'heure mémorisée de la barre zéro avec l'heure actuelle de la barre zéro.

Cette conception est plus fiable.

J'ai procédé de cette manière :

bool CUniexp::checkNewBar(void)
{
   static datetime prevTime[1];
   datetime currentTime[0];
   CopyTime(_Symbol,_Period,0,1,currentTime);
   if (currentTime[0]==prevTime[0])
   {return (false);}
   else
   {
      prevTime[0] = currentTime[0];
      return (true);
   }
}

[Prival]

https://www.mql5.com/fr/code/107

[ORIONIS]

Compile mais le débogueur échoue.

Le chargement de C:\NProgram Files\NMetaTrader 5\NMQL5\NExperts\NExemples\NMyEA.ex5 a échoué.

[echostate]

Rosh:

Un nouvel article Le prototype du robot commercial est publié :

Auteur : Алексей Сергеев

Merci pour cet excellent article ! Je suis un nouveau venu mais j'ai une question à propos du code.

Dans la fonction void CExpertAdvisor::TrailingPosition(long dir,int TS), il y a une ligne :

sl=NormalSL(dir,apr,apr,TS,StopLvl) ; // calculer le Stop Loss

Devons-nous utiliser apr pour le deuxième et le troisième argument lorsque nous appelons NormalSL ? Je pensais que c'était le cas :

sl=NormalSL(dir,op,apr,TS,StopLvl) ;

puisque le deuxième argument devrait être le cours acheteur/vendeur pour la direction "spécifiée" (c.-à-d. la variable op) plutôt que la direction "inverse" (c.-à-d. la variable apr).

Merci de votre compréhension.

[---]

echostate:

Dans la fonction void CExpertAdvisor::TrailingPosition(long dir,int TS), il y a une ligne :

sl=NormalSL(dir,apr,apr,TS,StopLvl) ; // calculer le Stop Loss

Devons-nous utiliser apr pour le deuxième et le troisième argument lorsque nous appelons NormalSL ? Je pensais que c'était le cas :

sl=NormalSL(dir,op,apr,TS,StopLvl) ;

Non.
les deuxième et troisième arguments doivent être apr.

parce que le calcul du tral est dérivé du prix auquel la position sera clôturée. La fonction Bid pour l'achat et Ask pour la vente est correcte.

car le deuxième argument doit être le prix acheteur/vendeur pour la direction "spécifiée" (c'est-à-dire la variable op) plutôt que la direction "inverse" (c'est-à-dire la variable apr).

doit être calculé à partir du sens "inverse". Dans ce cas, apr.

[echostate]

sergeev:

non.
les deuxième et troisième arguments doivent être apr.

car le calcul du tral est dérivé du prix auquel la position sera clôturée. La fonction Bid pour l'achat et Ask pour la vente est correcte.

Le tral doit être calculé à partir de la direction "inverse". Dans ce cas, apr.

Merci pour votre réponse rapide ! J'ai pensé que je devais me tromper.

Puis-je également demander dans la fonction

double CExpertAdvisor::CountLotByRisk(int dist,double risk,double lot) // calculer le lot en fonction de la taille du risque
  {
   if(dist==0 || risk==0) return(lot);
   m_smbinf.Refresh();
   return(NormalLot(AccountInfoDouble(ACCOUNT_BALANCE)*risk/(dist*10*m_smbinf.TickValue())));
  }

pourquoi nous avons un "10" entre "dist" et "m_smbinf.TickValue()" dans la valeur de retour ? Je suppose que "dist" est le stop loss (en termes de pips), et "m_smbinf.TickValue()" est la valeur en dollars US par pip par lot pour la paire de devises. Je ne sais donc pas pourquoi nous multiplions un autre "10" entre les deux.

Je vous remercie de votre attention.

[NFTrader]

Merci beaucoup.

[Haitao Jiang]

Article très utile. Merci beaucoup !