Ce que rapportent les fonctions Lowest et Highest - page 6

Nouveau commentaire
 
Je me disais aussi qu'apparemment, dans cette situation, il ne s'agit pas de pomper, mais de commencer à construire la nouvelle barre sans attendre que l'histoire soit pompée. Et c'est un peu juste. Mais d'un autre côté, imaginez un conseiller expert en trading. Un échec de la connexion se produit, puis la connexion est rétablie. L'expert peut ouvrir une position sur la base des valeurs erronées de l'indicateur jusqu'à ce que l'historique soit complètement interverti. La question dépasse donc le cadre de ce sujet et concerne la sécurité du trading automatique en général. Le problème n'est pas simple, bien sûr. Peut-être, la solution serait une variable prédéfinie "longueur de la dernière période continue de l'histoire" ? Les indicateurs (experts) pourraient le lire et gérer la situation d'une manière ou d'une autre.
 
C'est là que le stockage de la valeur des barres (et pas seulement de Time[0]) peut être utile. C'est-à-dire :

start() {..... if (PrevBars!=Bars-1) { init() ; PrevBars=Bars-1 ; }
 
Ceux qui font du trading sérieux d'EA sont probablement conscients de ce problème. Et une sorte de traitement pour cette situation est incluse dans l'EE.
 
Le stockage des valeurs des barres (pas seulement Time[0]) .... peut aider.

Voici un fragment de ce fichier journal qui montre que lorsqu'une nouvelle barre commence, les barres augmentent de 1 et non du nombre de barres à mettre à jour. Cela ne sert donc à rien
2006.10.31 23:58:25 CZZ2 EURUSD,M1 : shift=0, Bars=38230, Time[shift]=2006.10.31 22:51, High[shift]=1.2763, Low[shift]=1.2763 2006.10.31 23:58:25 CZZ2 EURUSD,M1 : shift=1, Bars=38230, Time[shift]=2006.10.31 22:45, High[shift]=1.2762, Low[shift]=1.2762 2006.10.31 23:58:23 CZZ2 EURUSD,M1 : shift=0, Bars=38229, Time[shift]=2006.10.31 22:45, High[shift]=1.2762, Low[shift]=1.2762



Ceux qui font du trading sérieux d'EA sont probablement conscients de ce problème. Et une sorte de traitement pour cette situation est incluse dans l'EE.

Nous pouvons essayer de gérer la situation d'une manière ou d'une autre, mais il semble que nous ne puissions pas nous passer de certaines astuces. Surtout si l'on tient compte de la position rigide de MQ sur les cartes sans trous.
D'autre part, le terminal sait s'il a besoin de pomper l'historique ou non. Si MQL avait accès à ces connaissances, le problème serait résolu beaucoup plus naturellement.


 
Ensuite, nous comparons Time[0] et Time[1]. Je n'ai moi-même été confronté qu'une seule fois à une telle situation, je ne peux donc pas vous donner un code pratique dès le départ.
 
Ensuite, nous comparons Time[0] et Time[1]. Je n'ai moi-même été confronté qu'une seule fois à une telle situation, je ne peux donc pas vous donner de code pratique. <br / translate="no">.

Cela ne fera rien si vous n'activez pas d'abord le code du type "graphique sans trous", car l'existence de trous est une situation normale dans MT. Bien que sur de grandes périodes de temps, il attrape presque tous les échecs.
 
En fait, il s'agit d'une sorte de "diabolisation" :)
Le code doit être écrit avec une protection maximale, car le pompage des données peut être causé non seulement par le terminal, mais aussi par le FAI, le centre de données, le courtier, le blocage de l'ordinateur, etc.
 
Au fait, juste au cas où. 28. Recherche de prix extrêmes - http://www.alpari-idc.ru/ru/experts/articles/29.html
 
Je crains que le code avec une protection maximale ne soit pas adapté à un usage pratique :). Comme le commerce est risqué en général, nous aurions pu nous limiter à une protection raisonnable. Mais nous parlons ici d'une situation assez fréquente. Au fait, ma conclusion sur la meilleure sécurité des grandes échéances dans le post précédent était erronée. La barre précédente peut avoir des valeurs High, Low et Сlose incorrectes avant l'échange d'historique, tandis que la barre actuelle a des valeurs High, Low et Open incorrectes.
 
Oui, il s'avère que les grandes échelles de temps sont encore plus dangereuses que les petites, car je ne vois pas de moyens simples de déterminer l'exactitude des données des deux dernières barres. Vous pouvez imaginer un indicateur accroché aux minutes et remplissant la variable globale GoodHistoryDepht. D'autres indicateurs vérifient cette valeur par rapport à leur profondeur de calcul requise et prennent des décisions. Mais en raison de la position du MQ sur les trous, une grande partie du temps (et plus l'horizon temporel est long, plus il est grand, jusqu'au rejet complet des barres quotidiennes) sera tout simplement impropre au trading. D'autant plus que les échecs de communication préfèrent vivre dans des comptes réels.
1234567
Nouveau commentaire
Raison: