Discussion de l'article "Contrôler la Pente de la Courbe d' Équilibre Pendant le Travail d'un Expert Advisor" - 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
solandr:
J'ai réalisé l'expérience suivante. J'ai réglé le compteur pour qu'il déclenche un lot réduit pour chaque paire de devises. Et j'ai testé toutes les combinaisons de tests sur M1 OHLC. Voici le résultat.
35 0 0 - test uniquement sur la première paire
0 36 0 - test uniquement sur la deuxième paire
0 0 0 168 - test uniquement sur la troisième paire.
36 35 0 0 - test sur la première et la deuxième paire
0 35 162 - essai sur la deuxième et la troisième paire
35 35 166 - test sur les trois paires
Bien qu'il faille utiliser 35 36 168 lorsque les tests portent sur les trois paires.
Demain, j'essaierai d'exécuter l'EA sur tous les ticks à des fins de comparaison.
Si je comprends bien, le nombre de transactions est différent ? Alors comment la taille du lot peut-elle l'affecter ?
Si je comprends bien, le nombre de transactions diffère ? Comment la taille du lot peut-elle l'influencer ?
Non, le nombre total de transactions sur 3 paires de devises en même temps correspond à la somme des transactions effectuées dans des cycles distincts.
Les résultats montrent le nombre d'ordres ouverts avec un lot réduit.
Je continue à utiliser l'Expert Advisor. J'essaie de comprendre ce qui modifie les résultats de l'exécution totale. J'écrirai un message plus tard.
Non, le nombre total de transactions sur 3 paires de devises en même temps correspond à la somme des transactions effectuées dans des séries distinctes.
Les résultats montrent le nombre d'ordres ouverts avec un lot réduit.
Je continue à utiliser l'Expert Advisor. J'essaie de comprendre ce qui modifie les résultats de l'exécution totale. J'écrirai un message plus tard.
Il est probable qu'en raison de conditions changeantes, les profits/pertes des transactions changent légèrement d'un cycle à l'autre - en conséquence, à certains points de la courbe d'équilibre, le changement de lot peut (ou ne peut pas) se produire.
Voici comment cela se passe.
Il se peut qu'en raison de conditions changeantes, les profits/pertes des transactions varient légèrement d'un cycle à l'autre - en conséquence, la permutation des lots peut (ou ne peut pas) se produire à certains points de la courbe d'équilibre.
C'est à peu près ce qui se passe.
En principe, l'idée est bonne. Sous MT4, j'utilise même un programme spécial, Spread Changer, qui permet de fixer arbitrairement l'écart pour les tests, et les résultats ne flottent pas.
Je n'ai pas encore trouvé un tel programme pour MT5 (peut-être n'ai-je pas bien cherché). Il serait bon que, dans les prochaines versions du terminal, les développeurs intègrent une telle fonction dans le testeur pour ceux qui le souhaitent.
En principe, l'idée est bonne. Sous MT4, j'utilise même un programme spécial, Spread Changer, qui permet de fixer arbitrairement l'écart pour les tests. et les résultats ne flottent pas.
Je n'ai pas encore trouvé un tel programme pour MT5 (peut-être n'ai-je pas bien cherché). Il serait bon que dans les prochaines versions du terminal, les développeurs intègrent une telle fonction dans le testeur pour ceux qui le souhaitent.
J'ai exécuté l'EA sur tous les ticks. J'ai obtenu les résultats suivants :
Avec la gestion de la balance désactivée, profit sur les runs :
0 0 0 0 0 6702,44 première paire
0 0 0 0 0 5735.78 deuxième paire
0 0 0 0 0 3461.48 troisième paire
0 0 0 0 15901.66 les trois paires - aurait dû être 15899.7. La différence est de 1,96.
Avec la gestion des lots activée, le profit sur les courses est de 35 0 0 = 6550,94
35 0 0 = 6550,94
0 36 0 = 6956,95
0 0 184 = 3386.44
35 36 179 = 15991.56 - aurait dû être 16894.33. La différence est de 902,77
Comme vous pouvez le constater, lorsque l'équilibrage automatique est désactivé, il y a également une différence, mais elle est généralement microscopique. Lorsque le contrôle des lots est activé, la différence est tout à fait notable : 5,3 % (en raison du nombre différent de déclenchements du lot réduit). Comment optimiser les paramètres ici ? Quelle solution peut-on inventer ?
Chaque exécution sur tous les ticks prend environ 20 à 30 minutes.
Je vais mettre en place une telle expérience. Prenez un Expert Advisor simple, ajoutez-y un système de contrôle des lots et voyez la différence dans les exécutions.
D'ailleurs, lors de la compilation du fichier mqh de l'article, j'obtiens ces messages :
perte possible de données due à une conversion de type BalanceSlopeControl.mqh 117 25
perte possible de données due à une conversion de type BalanceSlopeControl.mqh 118 21
la déclaration de 'current_slope' cache la déclaration d'un membre à la ligne 682 BalanceSlopeControl.mqh 909 9
0 erreur(s), 3 avertissement(s) 1 4
Je les ai corrigées au tout début. Pour les deux premiers, j'ai spécifié le type de conversion. Et j'ai corrigé le troisième message en corrigeant le nom de ccurrent_slope à la ligne 909 et la correction correspondante plus loin dans double TBalanceSlopeControl::CalcTradeLots( double _min_lots, double _max_lots ).
C'est peut-être là que le chien est enterré ? En tout cas, il serait possible de poster le fichier corrigé par l'auteur lui-même, car mes modifications peuvent être idéologiquement erronées.
J'ai exécuté l'EA sur tous les ticks. J'ai obtenu les résultats suivants :
...
Comme vous pouvez le voir, lorsque l'auto-balance est désactivée, il y a également une différence, mais elle est généralement microscopique.
Obtenez des résultats identiques dans tous les modes lorsque vous effectuez des tests sur n'importe quel symbole.
Pour ce faire, travaillez soit par ticks de tous les symboles, soit par timer. et contrôlez l'apparition d'une nouvelle barre sur tous les instruments.
La balance ne doit pas diverger d'un centime.
D'ailleurs, en compilant le fichier mqh de l'article, j'obtiens ces messages :
perte possible de données due à une conversion de type BalanceSlopeControl.mqh 117 25
perte possible de données due à une conversion de type BalanceSlopeControl.mqh 118 21
la déclaration de 'current_slope' cache la déclaration du membre à la ligne 682 BalanceSlopeControl.mqh 909 9
0 erreur(s), 3 avertissement(s) 1 4
Je les ai corrigées au tout début. Pour les deux premiers, j'ai spécifié le type de conversion. Et j'ai corrigé le troisième message en corrigeant le nom de ccurrent_slope à la ligne 909 et la correction correspondante plus loin dans double TBalanceSlopeControl::CalcTradeLots( double _min_lots, double _max_lots ).
C'est peut-être là que le chien est enterré ? En tout cas, il serait possible de poster le fichier corrigé par l'auteur lui-même, car mes modifications peuvent être idéologiquement erronées.
C'est peu probable ici. Je me souviens d'une règle, mais de quoi - je ne me souviens pas))) Voici mon fichier actuel.
Je ne pense pas que ce soit le cas ici. Je me souviens d'une règle, mais de quoi - je ne me souviens pas))) Voici mon fichier actuel.
Merci pour la nouvelle version du fichier !
La comparaison du contenu du fichier avec le fichier de l'article montre quelques différences dans le nouveau fichier aux lignes 37, 115, 116, 907, 966.
Voyons dans quelle mesure ces changements peuvent affecter l'Expert Advisor