Algorithmes, méthodes de résolution, comparaison de leurs performances - page 23
![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Vous pourriez simplement avoir un intervalle plus long. Au moins 30 secondes pour le test.
Avec la normalisation.
Sans normalisation.
Les mêmes 20%.
C'est ainsi que fonctionne un agent, qui compte toujours la même chose. Si vous enlevez tout le caractère aléatoire, la performance nette est proche de la plus courte.
Net n'est pas intéressant, car il n'est pas réalisable dans la réalité.
Merci pour les tests.
Avec la normalisation.
Sans normalisation.
Les mêmes 20%.
20% pour une EA factice qui ne fait rien... Ce n'est pas très significatif. Dans un code réel, le chiffre serait beaucoup moins élevé. Cela vaut-il la peine de perdre du temps sur de telles futilités ?
En parlant d'optimisation des calculs, commençons par le fait qu'il n'est pas nécessaire de surveiller constamment les niveaux de tous les ordres en attente. Nous devons seulement vérifier le plus proche. S'il est atteint, on passe au niveau suivant et ainsi de suite.
20% pour une EA factice qui ne fait rien... Ce n'est pas très significatif. Dans un code réel, le chiffre serait beaucoup moins élevé. Cela vaut-il la peine de perdre du temps avec de telles futilités ?
L'observation est juste. Sur mon robot normal, je vois trop de décalage dans le Tester. Il y a plusieurs raisons à cela. Et c'est l'un d'entre eux. Un passage correspond à 100 millions de tics. Prenons la génétique standard pour les passages de 10K. C'est un trillion de tics au moins. À chaque tic, le testeur effectue au moins une normalisation. Alors qu'elle ne pouvait rien faire du tout. Quelle est l'économie d'une telle optimisation ? De plus, s'embêter, c'est faire une normalisation à chaque comparaison, comme c'est le cas actuellement. Il est en fait plus facile et plus efficace de normaliser uniquement les prix entrants.
Et en parlant de l'optimisation des calculs, nous devons commencer par le fait que nous n'avons pas besoin de surveiller constamment les niveaux de tous les ordres en attente. Nous devons seulement vérifier le plus proche. S'il est atteint, le niveau suivant est vérifié, etc.
Le testeur intégré accuse un retard considérable lorsque le nombre de commandes augmente. Les TS du réseau sont ses "tueurs". J'ai suggéré une telle optimisation algorithmique. Je ne pense pas qu'ils l'entreprendront.
Nous ne parlons pas ici d'une grande quantité de calculs internes accompagnant chaque tic-tac du testeur.