Pas pour les développeurs MT ! Par quoi remplacer INIT_PARAMETERS_INCORRECT ? - page 2
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 pouvez créer votre propre ensemble d'optimisation dans OnTesterInit et faire en sorte que l'optimiseur pense qu'un seul sinput int NumPass est optimisé.
Il est difficile de dire quel effet cela aura sur le résultat final - si l'extrémum global (local) souhaité sera trouvé.
Je ne suis pas prêt à vous fournir un exemple, jetez un coup d'œil à la documentation. C'est bien écrit là.
Une des recettes consiste pour les développeurs à faire compter le résultat des passes INCORRECTES comme la passe CORRECTE la plus proche précédemment comptée. Cela permettra d'égaliser les trous dans la surface d'optimisation.
C'est ce à quoi s'opposent les développeurs. Dans ce cas, les autres individus de la population "survivront". Et la génétique va commencer à fonctionner avec des erreurs.
Pourquoi ne pas écrire une fonction qui ne produit que les chaînes valides par numéro ?
La première chose qui vient à l'esprit est un tableau de 117649 valeurs, et la génétique cherche des chiffres dans ce tableau.
C'est ce à quoi s'opposent les développeurs. Dans ce cas, les autres individus de la population "survivront". Et la génétique commencera à mal fonctionner.
Je serais également contre un tel algorithme. INCORRECT est un jeu de paramètres inacceptable, il ne peut être remplacé par le jeu de paramètres "acceptable le plus proche".
C'est ce à quoi s'opposent les développeurs. Dans ce cas, les autres individus de la population "survivront". Et la génétique commencera à fonctionner par erreur.
Dans la pratique, la génétique a presque toujours tort, ce qui est la norme. En l'absence de recherches appropriées dans ce domaine, je ne prétendrai rien sur l'option proposée.
Que diriez-vous d'une fonction qui renvoie uniquement les chaînes valides par numéro ?
La première chose qui vient à l'esprit est un tableau de 117649 valeurs et la génétique cherche des chiffres dans ce tableau.
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie
Pas pour les développeurs MT ! Par quoi remplacer INIT_PARAMETERS_INCORRECT ?
fxsaber, 2018.07.10 16:22
Vous pouvez créer votre ensemble d'optimisation dans OnTesterInit et faire en sorte que l'optimiseur pense qu'un seul sinput int NumPass est optimisé.
Il est difficile de dire quel effet cela aura sur le résultat final - si l'extremum global (local) requis sera trouvé.
Elle dépend fortement du critère de satisfaction du résultat final.
Il est évident que si nous suivons la recherche complète de y = x^2. Ensuite, mélangez aléatoirement les rangées et créez un nouvel ensemble basé sur le mélange. Alors GA ne trouvera pas le sommet de la parabole.
Évidemment, si vous tracez une énumération complète de y = x^2. Ensuite, mélangez aléatoirement les rangées d'opimisation et créez un nouvel ensemble basé sur le mélange. L'AG ne trouvera pas le sommet de la parabole.
Oui, il s'avère ici que ces très INCORRECTs "déchirent" trop l'espace de la fonction de fitness.
J'ai bien peur qu'il n'y ait rien à faire, à part revoir les paramètres d'entrée. Sauter OnTick() comme vous le suggérez n'est qu'une béquille pour remplacer un paramètre INCORRECT, en réalité l'algorithme génétique est "tué" de toute façon. La génétique nécessite quelques "gradients" de la fonction de résultat, afin que nous puissions les utiliser pour aller vers les maxima. Mais lorsque vous avez plus d'INCORRECTs que de valeurs valides - comment trouver ce maximum ?
Je pense qu'à l'exception de la force brute totale, vous ne pouvez rien faire, et même la force brute totale trouvera une solution très instable.Il faut un peu de doigté pour régler les paramètres d'entrée.
Un exemple très courant peut être donné. Lors de l'optimisation de l'intervalle de trading quotidien, les heures de début et de fin de journée sont les deux paramètres d'entrée les plus courants.
Mais c'est bien pire pour GA que, par exemple, de spécifier l'heure de début et la durée. C'est apparemment la même chose, mais pas pour l'AG. Dans le second cas, l'AG ferait mieux. Bien que "meilleur" soit une évaluation plutôt subjective.
Georgiy Merts:
lorsque nous avons plus d'INCORRECTs que de valeurs valides - comment trouver ce maximum ?
Prenons la même parabole que ci-dessus. Supposons que nous fassions un INCORRECT sur l'intervalle de test de 90% de la valeur d'un seul paramètre d'entrée. L'AG actuelle se plantera sur une telle tâche. Toutefois, si vous suivez l'option suggérée, l'AG se portera bien.
Je pense que @Andrey Dik peut vous aider sur ces questions. Mais même la critique constructive de l'AG régulière ne s'est pas bien terminée pour lui...
Prenez la même parabole que ci-dessus. Supposons que nous fassions INCORRECT sur l'intervalle de test 90% de la valeur du paramètre d'entrée unique. L'AG actuelle mourrait sur une telle tâche. Cependant, si vous procédez avec la variante suggérée, le GA fera l'affaire.
Comment ? En remplaçant les incorrections par les corrections les plus proches ? ?? Je crains que tout dépende de la façon dont nous distribuons ces mêmes incorrections. Il est tout à fait possible que les corrections les plus proches - soient éloignées du sommet.
Oui, et il s'avérera qu'au lieu d'avoir des ensembles de paramètres erronés, nous aurons des résultats corrects - ce qui, à mon avis, ne devrait pas être fait - que trouverons-nous alors ? Nous obtiendrons un maximum et il aura un paramètre incorrect ?