Pas pour les développeurs MT ! Par quoi remplacer INIT_PARAMETERS_INCORRECT ? - 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
J'ai créé un conseiller expert de test pour le mode mat de l'Optimiseur.
Voici à quoi ressemble un graphe d'optimisation pour 8 agents en parallèle en mode force brute complète sans passes entrelacées (Rand = false)
On peut clairement voir ici que les agents exécutent les tâches par lots.
Afin de voir la dépendance au paramètre, changeons de mode d'affichage.
La voici - une parabole native, dont nous chercherons le sommet (unité) à travers GA.
En mode shuffle (Rand = true), bien sûr, la force brute totale trouve notre sommet.
Voici la parabole native, dont le sommet (un) sera recherché par GA.
Sans le mélange GA, je n'ai pas trouvé l'extremum, mais je m'en suis approché.
Il a fallu 179 passages. Je vous rappelle que l'ensemble des tâches représente 10001 passages. Oui, le problème est très simple, mais quand même.
Essayons maintenant la variante avec brassage (Rand = true).
Fermez encore. On le voit clairement dans le journal, 182 passes ont été entièrement calculées, et 970 ont été prises dans le cache.
Bon résultat, donc, essayons d'augmenter le nombre de points dans l'intervalle.
C'est un bon résultat, alors essayons d'augmenter le nombre de points dans l'intervalle.
Le nombre de points dans l'intervalle est de un million.
Rand = false
Rand = vrai (sur un million de points, des paires choisies au hasard ont été échangées 100 millions de fois)
Le résultat montre que ma déclaration pleine d'assurance
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading.
Pas pour les développeurs MT ! Par quoi remplacer INIT_PARAMETERS_INCORRECT ?
fxsaber, 2018.07.10 16:27
É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. Alors l'AG ne trouvera pas le sommet de la parabole.
C'est plutôt faux que vrai.
D'autre part, le choix de la fonction de fitness sous la forme d'une parabole était initialement très peu perspicace, car le nombre de points proches de un est hors norme.
Il n'y a qu'une seule question pour l'AG, pourquoi l'extremum exact n'a pas été trouvé sans mélange, puisque la fonction choisie est idéale pour cela ?
D'autre part, le choix d'une fonction d'aptitude sous forme de parabole était initialement extrêmement peu perspicace, car le nombre de points proches de un est hors normes.
Je suppose que si vous choisissez une fonction avec un pic aigu, le GA se cassera quand même après le mélange. Et une telle fonction est beaucoup plus proche de TC.
J'ai mis en place un EA de test pour le mode mathématique de l'Optimizer.
Malheureusement, mes connaissances ne sont pas suffisantes pour tout comprendre )))).
J'ai décidé de faire plus simple. En général, j'ai ajouté à mon conseiller expert un enregistrement dans le fichier des chaînes légitimes. J'ai trouvé 1953 variantes possibles sur 117649. D'ailleurs, il m'a fallu 3 jours pour faire la recherche complète sur un intervalle de 3 jours, uniquement des prix ouverts et 0 transaction.
J'ai un dossier maintenant. Je ne sais pas encore comment l'utiliser pour l'optimisation. Je vais y réfléchir demain...
Et pourquoi les succès sont-ils moins nombreux ? Devrons-nous le faire à nouveau ?Je suppose que si vous sélectionnez une fonction avec un pic aigu, le GA se brisera quand même après le mélange. Et une telle fonction est beaucoup plus proche de TC.
La génétique n'est donc pas conçue pour repérer les pics. Son but est de trouver des régions stables, ce que requiert le TC. Et les pics sont du bruit, en règle générale.
Quant aux combinaisons de paramètres incorrectes, elles doivent être éliminées au stade de la formation de la population, c'est-à-dire que si un échange de gènes ou une mutation aboutit à un individu incorrect, il est nécessaire de répéter sa génération jusqu'à l'obtention de l'individu correct. Alors tout sera OK.
Si le criblage parINIT_PARAMETERS_INCORRECT se produit après la formation de la population, réduisant ainsi la taille de cette population, alors bien sûr cela viole le mécanisme normal de sélection génétique. Apparemment, MQ a cette variante. Et dans ce cas, la tâche du topicstarter est difficilement soluble (dans le cas général), danser avec des tambourins n'aidera pas.
Merci pour votre opinion, mais il n'y a pas de discussion ici sur l'architecture du programme. Au cas où vous n'auriez pas remarqué...
Faux, faux.
Je suis d'accord que votre problème est exactement la mauvaise architecture du programme. Je pense que vous ne pouvez obtenir le maximum que par la force brute totale, et ce sera très instable.
Il est fort probable que des dépassements complets soient utilisés à chaque tic. Cela entraîne en soi une lenteur de fonctionnement. Si c'est le cas, nous devrions envisager d'utiliser des recherches complètes uniquement au démarrage/à la barre d'ouverture du conseiller expert, puis de vérifier les dernières données. Une telle optimisation réduit toujours la consommation de ressources.
La génétique n'est pas conçue pour repérer les pics. Son but est de trouver des régions stables, ce que requiert le CT. Et les pics sont du bruit, en règle générale.
Ce n'est pas tout à fait le cas. De plus, même les zones stables de l'espace d'optimisation sont toujours des zones avec des creux et des pics, la FF est loin d'être lisse.
Genetics est un outil polyvalent, il pourrait être modifié pour optimiser un FF corrompu mais dans ce cas, il faudra plus de temps pour optimiser un FF lisse.
Je pense que la génétique standard devrait digérer les ensembles avec la moitié de INIT_PARAMETERS_INCORRECT sans même y penser. D'autant plus que ces zones sont généralement bien groupées.
mais en général, la meilleure solution est de transformer l'espace des paramètres d'entrée.
En vain, en vain.
Je suis d'accord pour dire que votre problème réside dans la mauvaise architecture du programme. Je pense que vous ne pouvez obtenir le maximum que par la force brute totale, et ce sera très instable.
Il ne s'agit pas d'architecture. Il s'agit de l'ensemble des fonctions et de l'ordre dans lequel elles sont appliquées. En fait, à l'origine, ces fonctions avaient une seule séquence constante. Puis j'ai décidé que je devrais peut-être expérimenter l'ordre dans lequel je les appelle et n'appelle pas certains d'entre eux. Je l'ai implémenté par le biais de INIT_PARAMETERS_INCORRECT. Vous pouvez voir les progrès. Mais j'ai un problème avec l'optimisation génétique.
Venons-en au fait. J'ai créé un fichier avec des chaînes légitimes. Comment l'utiliser maintenant ? Je pense que je devrais utiliser onTester, les cadres... J'ai regardé la documentation, mais quelque chose ne colle pas. Je ne sais pas comment m'y prendre.
Je pense le lire dans un tableau et en extraire des données...