Archives de la version MT. - page 4
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Dans ce contexte, ne pouvons-nous pas faire la vérification ?
Malheureusement, cette vérification n'a rien donné...
En donnant un exemple avec IsStopped(), j'essayais juste de répondre à la première partie.
Parfois, il est nécessaire de terminer le traitement d'un événement à l'avance, et parfois c'est urgent comme dans votre cas.
Lisez la description de cette fonction IsStopped() dans la documentation, cela vous donnera peut-être des idées.
Mais il vous semble que ça vient d'une autre direction. S'il s'agit d'un autre fil de discussion, je m'excuse de l'avoir deviné.
Mais comme on dit dans les suggestions possibles, et résout le problème.
La solution définitive ne le dira à personne, car personne ne connaît toute la logique de son code, et ne s'y plongera probablement pas.
Roman, encore une fois, tu ne cites pas tout le long. Et vous l'avez mis en évidence parmi tous ceux qui ont été mis en évidence.
Bon, d'accord, disons qu'un arrêt forcé est lancé. Et j'ai besoin que cet événement de terminaison soit exécuté jusqu'à la fin et que la complexité des calculs dépasse 3 secondes. Et comment puis-je empêcher l'arrêt du programme et le laisser se dérouler jusqu'à la fin ? C'est exactement le problème. La conversation n'a pas porté sur la manière de mettre fin à une situation, mais sur la manière d'empêcher une cessation d'activité invoquée de manière incorrecte. Ou pas pour empêcher, mais pour retarder jusqu'à un certain point, en particulier jusqu'à ce que le traitement de l'événement soit terminé.
Voici une vérification de votre option. Il s'est retrouvé avec un message comme celui-ci :
C'est une impasse...
L'option suggérée est donc
se dérouleront exactement de la même manière. Et vous obtiendrez à nouveau une "impasse". Mais l'impasse n'est pas dans mql, mais dans votre esprit. Ce n'est pas une façon de faire de la programmation. Avant d'attendre quoi que ce soit du code, imaginez-vous à la place d'un idiot et, sans ménagement, comme le fait un ordinateur, parcourez plusieurs fois l'ensemble du code. Assurez-vous de l'endroit où l'exécution doit être passée dans un cas particulier. Quels paramètres doivent être reçus dans un cas particulier. Ensuite, lancez l'exécution et vérifiez si nous obtenons ce que nous attendons. Si ce n'est pas le cas, nous devons trouver d'où vient ce que nous voyons pendant le processus de débogage.
Il ne peut en être autrement. Et il est absolument impossible de déboguer les fragments de code.
Roman, encore une fois, tu ne cites pas tout le long. Et vous avez mis en évidence parmi toutes les mises en évidence.
Bon, d'accord, disons qu'un arrêt forcé est déclenché. Et j'ai besoin que l'événement dans lequel cette terminaison est déclenchée soit exécuté jusqu'à la fin et que la complexité des calculs dépasse 3 secondes. Et comment puis-je empêcher l'arrêt du programme et le laisser se dérouler jusqu'à la fin ? C'est exactement le problème. La conversation n'a pas porté sur la manière de mettre fin à une situation, mais sur la manière d'empêcher une cessation d'activité invoquée de manière incorrecte. Ou pas pour empêcher, mais pour retarder jusqu'à un certain point, en particulier jusqu'à ce que le traitement de l'événement soit terminé.
Nous devons attendre que le calcul soit terminé.
Malheureusement, mql ne contient pas de fonctions comme await.
Nous pouvons essayer d'expérimenter avec Sleep(), mais le glissement n'est pas un signe explicite de fin, donc ce n'est pas très approprié.
Essayez de créer une autre condition, si(le calcul est exécuté), alors nous allons déjà commencer une terminaison forcée.
Donc l'option que je propose
se dérouleront exactement de la même manière. Et une fois de plus, vous obtiendrez une "impasse". Mais l'impasse n'est pas dans mql, mais dans votre esprit. Vous ne pouvez pas vous lancer dans une telle programmation. Avant d'attendre quoi que ce soit du code, imaginez-vous à la place d'un idiot et parcourez aveuglément, comme le fait un ordinateur, l'ensemble du code plusieurs fois. Assurez-vous de l'endroit où l'exécution doit être passée dans un cas particulier. Quels paramètres doivent être reçus dans un cas particulier. Ensuite, lancez l'exécution et vérifiez si nous obtenons ce que nous attendons. Si ce n'est pas le cas, nous devons trouver d'où vient ce que nous voyons pendant le processus de débogage.
Il ne peut en être autrement. Mais vous ne pouvez pas déboguer le code fragment par fragment.
Le problème, c'est que tout fonctionnait avant la mise à jour et que maintenant je ne sais plus quoi faire.
En outre, tout le code est ouvert en principe.
De plus, je voulais ouvrir un fil de discussion pour discuter de l'amélioration de ma version OnTester() et le voici...
Il s'est avéré que le problème ne se situe pas au niveau de l'exécution de TesterStop(), mais plutôt au niveau de l'exécution modifiée de TesterStop(). En fait, il n'y a pas de lien direct avec OnTester(), mais cela a gâché mon humeur...
Je vais essayer autre chose maintenant...
C'est ça le problème, avant la mise à jour tout fonctionnait, mais maintenant je ne sais plus quoi faire.
D'ailleurs, en principe, tout le code est ouvert.
De plus, je voulais déjà ouvrir un fil pour discuter de l'amélioration de ma version OnTester() et le voici...
Il s'est avéré que le problème ne se situe pas au niveau de l'exécution de TesterStop(), mais plutôt au niveau de l'exécution modifiée de TesterStop(). En fait, il n'y a pas de lien direct avec OnTester(), mais cela a gâché mon humeur...
Je vais essayer autre chose maintenant...
Vous avez donné un lien vers les constructions précédentes. Remplacez les fichiers et vérifiez-les. Vous pourrez alors dire à tout le monde quel build fonctionne maintenant. Si cela ne fonctionne pas, cela signifie que les paramètres qui ne menaient pas à cette partie du code où les problèmes apparaissent maintenant étaient simplement les mêmes.
Je vous ai donc donné un lien vers les constructions précédentes. Remplacez les fichiers et vérifiez. Ensuite, vous pourrez dire à tout le monde quel build fonctionne maintenant. Si cela ne fonctionne pas, cela signifie que les paramètres qui ne mènent pas à cette partie du code, où il y a maintenant un problème, ont simplement coïncidé.
C'est comme ça que je l'ai essayé. Mettez en place la construction 2007 et là, tous ces problèmes ont disparu. J'ai spécifiquement regardé l'ensemble du journal après l'optimisation. J'ai trouvé 4 (seulement 4 !) erreurs de division par zéro. Ce sont celles qui ont eu lieu lorsqu'il n'y avait pas de commerce. Bien sûr, cela devait être corrigé, mais cela n'a eu aucun effet sur le résultat global de l'optimisation ! Mais la nouvelle construction a provoqué une quantité alarmante d'erreurs et rendu l'optimisation impossible.
Maintenant, en ce qui concerne le conseil de @Roman.
Merci, c'était un bon. Mais dans mon cas, il s'est avéré inutile pour TesterStop() parce que TesterStop() exige que le test ait déjà passé un certain pourcentage inconnu. Et il n'y a pas un mot à ce sujet dans la documentation.
Mais cela a bien fonctionné avec ExsprtRemove(). Le nombre de tests passés n'a pas d'importance pour cette fonction. Mais nous avons dû envelopper tout le code de travail dans le if.
Eh bien, j'ai réussi à réparer le code avec des béquilles. Merci encore.
P.S. En fait, j'ai dû fabriquer une béquille pour une autre béquille. Drôle ))))
P.S. En fait, j'ai dû fabriquer une béquille pour l'autre béquille. C'est drôle ))))
Je ne crois pas qu'il n'y ait pas d'options. Si vous aimez programmer des béquilles aux béquilles, je n'ai pas le droit d'empêcher. Slava a répondu à ce sujet.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
Bugs, bugs, questions
Slava, 2019.06.16 14:04
L'arrêt immédiat de l'Expert Advisor signifie une corruption de la mémoire. Après un arrêt immédiat du conseiller expert, il peut y avoir des blocs de mémoire non libérés. Par conséquent, l'arrêt immédiat du conseiller expert n'est utilisé que lorsque le terminal client ou l'agent de test est interrompu et seulement si le conseiller expert ne traite pas le drapeau d'arrêt et poursuit l'exécution.
TesterStop donne la commande pour terminer le test. Cela signifie qu'une fois que le gestionnaire actuel OnInit, OnTick, OnTimer, OnChartEvent est terminé, aucun autre événement du testeur ne sera traité, car le cycle de traitement est terminé. A la place, OnTester et OnDeinit seront appelés.
C'est comme ça que je l'ai essayé. Mettez en place la construction 2007 et là, tous ces problèmes ont disparu. J'ai spécifiquement regardé l'ensemble du journal après l'optimisation. J'ai trouvé 4 (seulement 4 !) erreurs de division par zéro. Ce sont celles qui ont eu lieu lorsqu'il n'y avait pas de commerce. Bien sûr, cela devait être corrigé, mais cela n'a eu aucun effet sur le résultat global de l'optimisation ! Mais la nouvelle construction a provoqué une quantité alarmante d'erreurs et rendu l'optimisation impossible.
Maintenant, en ce qui concerne le conseil de @Roman.
Merci, c'était un bon. Mais dans mon cas, il s'est avéré inutile pour TesterStop() parce que TesterStop() exige que le test ait déjà passé un certain pourcentage inconnu. Et il n'y a pas un mot à ce sujet dans la documentation.
Mais cela a bien fonctionné avec ExsprtRemove(). Le nombre de tests passés n'a pas d'importance pour cette fonction. Mais nous avons dû envelopper tout le code de travail dans le if.
Eh bien, j'ai réussi à réparer le code avec des béquilles. Merci encore.
P.S. En fait, j'ai dû fabriquer une béquille pour une autre béquille. Drôle ))))
Il ne s'agit pas d'une béquille, mais d'une pratique recommandée par les développeurs.
J'ai trouvé cette fonction dans la description de la boucle while
C'est pourquoi j'ai eu une idée : si cette fonction vérifiele fait que le programme est forcé de s'arrêter, pourquoi ne pas l'utiliser pour TesterStop().
C'est dommage que cela ne fonctionne pas pour TesterStop(), nous allons le savoir maintenant.
Mais il est juste de demander aux développeurs si la fonctionIsStopped() doit fonctionner pour la fonction TesterStop() ?
C'est peut-être un bug ?
Mais l'essentiel est la solution au problème.
Je ne crois pas qu'il n'y ait pas d'options. Si vous aimez programmer des béquilles pour des béquilles, je n'ai pas le droit d'interférer. Slava a répondu à ce sujet
Je comprends tout, et je n'ai pas besoin de béquilles. Et j'ai dû chercher une béquille ici, le lire pour quoi faire.
Peut-être. Mais je ne me souviens pas que quelqu'un s'en soit plaint.