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
J'ai écrit à ce sujet il y a longtemps, lorsque j'utilisais des cadres dans l'EA. Je ne me souviens pas du point exact, mais il semble que je n'obtienne pas toutes les images (et les meilleurs résultats). Je vais rechercher les anciens messages et essayer de les clarifier.
Mais je me souviens très bien qu'il était clairement reproductible dans mon Expert Advisor - dès que le nombre de dépassements dépassait un certain nombre et qu'il était affiché sous une forme scientifique, ma génétique était cassée. L'important n'était pas seulement que la variable ait un grand nombre d'étapes, mais que le nombre de variables soit également grand.
Tout a un sens.
Il y a un problème avec les cadres sur la "grande" génétique.
Nous allons le réparer.
Que voulez-vous dire par "il ne fonctionne pas du tout correctement" ?
Comment pouvons-nous reproduire le dysfonctionnement ?
https://www.mql5.com/ru/forum/321656/page17#comment_13569022
Je ne vérifie plus les cadres, j'ai abandonné.
Mais avec la génétique régulière, je l'ai vérifié lors de la dernière construction. Voici le résultat sans "débordement de chiffres".
Après l'interruption :
Avec "overflow" :
Après être passé par plusieurs passes interrompues par EA (vérifiant que les variables d'entrée sont correctes), la génétique s'est arrêtée définitivement. Après l'interruption :
Pas un seul résultat réel.
J'ai essayé Advisors/MAPSARSizeOptimized.ex5 comme exemple, il fonctionne. Il est clair que le problème du "digit overflow" et des frames ne se reproduit qu'avec mon EA, mais comment trouver le problème... Tout y est très compliqué, OnTradeTransaction etc. J'ai également retiré les cadres. Je ne peux pas vous montrer le code et il est énorme, environ un mégaoctet. Et le réduire à un exemple reproductible prendrait un temps désespérément long. Si j'ai le temps, je vais essayer de supprimer OnTradeTransaction et peut-être d'autres astuces.
Le fait est que si nous ne dépassons pas le nombre de passages, tout fonctionne bien.
Et les cadres fonctionnaient bien (sans dépassement) jusqu'à la build 2286 incluse.
...
un problème jusqu'à présent - les GA peuvent commencer à converger autour d'un petit groupe de paramètres d'optimisation après un certain temps - cela me semble normal, tous les GA fonctionnent de cette façon et c'est un problème de leur utilisation
...
La convergence vers un certain extremum est un phénomène parfaitement normal pour tout algorithme d'optimisation, il n'y a aucune raison de supposer que cette section n'est pas/est pas globale ou locale.
Par ailleurs, AO devrait avoir un mécanisme permettant d'amplifier le pourcentage de mutation (ou un autre équivalent dans la logique qui permet d'amplifier l'expansion du voisinage de recherche), lorsque l'on commence à piétiner un certain segment, l'extremum sera trouvé mieux ou non - on ne le sait pas à l'avance, mais il est certainement nécessaire de chercher dans d'autres endroits.
par exemple, un critère d'équilibre maximal est fixé, plusieurs ou beaucoup de points peuvent correspondre à ce critère en termes absolus mais seuls certains d'entre eux ont une valeur réelle, c'est-à-dire que l'équilibre 98756423 a été atteint à 1523 transactions avec un drawdown de 11% et le même équilibre a été atteint à 12 transactions avec un drawdown de 95%, quelle est la différence entre les deux ?
Après avoir subi plusieurs passages interrompus par l'expert (vérification que les variables d'entrée sont correctes), la génétique s'est arrêtée définitivement. Après l'interruption :
Pas un seul résultat réel.
Je ne me souviens pas si j'ai écrit à ce sujet sur le forum, mais c'est vraiment un problème et la raison pour laquelle il est implémenté dans MT n'est pas claire. Dans l'idée, si l'expert renvoie le code d'erreur "paramètres incorrects", le testeur est obligé de générer une autre instance à la place, afin que la population soit complète.
Je ne me souviens pas si j'ai écrit à ce sujet sur le forum, mais c'est vraiment un problème et la raison pour laquelle il est implémenté dans MT n'est pas claire. Dans l'idée, si l'expert renvoie le code d'erreur "paramètres incorrects", le testeur est obligé de générer une autre instance à la place, afin que la population soit complète.
Si je renvoie INIT_PARAMETERS_INCORRECT pour toutes les combinaisons de paramètres incorrectes, il y en a trop et la génération se terminera par une erreur. Ainsi, je ne renvoie INIT_PARAMETERS_INCORRECT que lorsqu'un paramètre spécifique est incorrect, s'il est hors limites. Et si la combinaison est incorrecte (un paramètre ne doit pas dépasser l'autre), j'arrête la passe, renvoie INIT_SUCCEEDED et Custom = -N. Cela fout probablement en l'air la génétique, mais je ne vois pas d'autres options. Ou plutôt, il existe une option qui permet de se débarrasser des combinaisons erronées (dans le cas particulier - faire d'un paramètre un delta par rapport à un autre : v1=X, v2=Y+v1), mais c'est un mutagène trop puissant. Les deux paramètres seront rigidement liés, et si vous en changez un, tout bascule. J'ai abandonné cette option en faveur d'un faux résultat au lieu d'une erreur.
Si vous renvoyez INIT_PARAMETERS_INCORRECT pour toutes les combinaisons de paramètres erronées, il y en a trop et la génération se terminera par une erreur. Je ne renvoie donc INIT_PARAMETERS_INCORRECT que lorsqu'un paramètre spécifique est incorrect, s'il est hors limites. Et si la combinaison est mauvaise (un paramètre ne doit pas dépasser l'autre), j'arrête la passe, renvoie INIT_SUCCEEDED et Custom = -N. Cela fout probablement en l'air la génétique, mais je ne vois pas d'autres options. Ou plutôt, il existe une option qui permet de se débarrasser des combinaisons erronées (dans le cas particulier - faire d'un paramètre un delta par rapport à un autre : v1=X, v2=Y+v1), mais c'est un mutagène trop puissant. Les deux paramètres seront rigidement liés, et si vous en changez un, tout bascule. J'ai renoncé à cette option en faveur d'un faux résultat au lieu d'une erreur.
Une bonne option est de retourner -DBL_MAX sur une variante invalide au lieu d'une erreur.
en général, j'ai réussi à mettre en œuvre Ga externe tout en conservant tous les charmes de la fidélité multi-devises du testeur MT, tout en étant capable d'utiliser tous les cœurs de CPU et/ou les agents de réseau, y compris les agents de nuage, tout en évitant les situations où les agents sont inactifs en raison de l'achèvement prématuré des passes ou de populations Ga en sous-effectif.
il y a des informations, seulement tSSSSS.... qu'il y a des plans pour implémenter plusieurs types d'AOs dans l'optimiseur régulier, et même avec des paramètres, mais ceci est inexact.
une bonne option est de retourner -DBL_MAX sur une variante invalide au lieu d'une erreur.
Et si vous renvoyez une valeur aléatoire, est-ce que ce sera pire pour l'AO ?
Et si vous renvoyez une valeur rendue, est-ce que c'est pire pour l'AO ?
bien pire.
Si le but est d'embrouiller la tête d'AO, le meilleur moyen est de renvoyer un nombre aléatoire.
une bonne option est de retourner -DBL_MAX en cas de variante invalide, au lieu d'une erreur.
C'est trop, le graphique est mis à l'échelle de sorte que vous ne pouvez pas voir les résultats utiles. Je renvoie une valeur légèrement supérieure à celle du pire cas de la coutume. L'essentiel, cependant, est de définir la bonne direction pour l'amélioration.
Et si vous renvoyez une valeur rendue, est-ce que ce sera pire pour l'AO ?
Quel est l'intérêt ? L'essentiel est de fixer la bonne direction, il faut donc montrer à GA qu'il a montré le pire résultat ici, et pas seulement un résultat faible.
Que voulez-vous dire par "ça ne marche pas du tout" ?
Comment puis-je reproduire l'erreur de l'opération ?
J'aisuppriméOnTradeTransaction, ça n'a pas aidé. Je vais continuer à penser.