L'optimisation dans le testeur de stratégie - page 10

 

Dans les dernières versions, nous avons complètement éliminé les surcharges du système lors de l'exécution des tâches, les faisant passer de près de 2000 ms à zéro.

Voici les résultats de l'exécution d'une tâche de calcul, qui a été suggérée par joo :

input double   x1=0.0;
input double   x2=0.0;
double OnTester()
  {
   return
   (
    pow(cos((double)(2*x1*x1))-0.11 e1,0.2 e1)+
    pow(sin(0.5 e0 *(double) x1)-0.12 e1,0.2 e1) -
    pow(cos((double)(2*x2*x2))-0.11 e1,0.2 e1)+
    pow(sin(0.5 e0 *(double) x2)-0.12 e1,0.2 e1)
    );
  }

Paramètres (les dates sont fixées exprès pour que l'historique du graphique ne soit pas utilisé) :

Paramètres à exécuter :

Agents utilisés (4 agents locaux) :

Résultats de l'optimisation :

L'optimisation n'a pris que 25 secondes, 18 432 passages ont été effectués :



Résultat global : MetaTrader 5 et son réseau d'agents peuvent être utilisés pour des calculs mathématiques massifs.

 
Renat:

Dans les dernières versions, nous avons complètement éliminé les surcharges du système lors de l'exécution des tâches, les faisant passer de près de 2000 ms à zéro.

Voici les résultats de l'exécution d'une tâche de calcul, qui a été suggérée par joo :

Paramètres (les dates sont fixées exprès pour que l'historique du graphique ne soit pas utilisé) :

Paramètres à exécuter :

Agents en service (4 agents locaux) :

Résultats de l'optimisation :

L'optimisation n'a pris que 25 secondes et 18 432 passages ont été effectués :

Résultat global : MetaTrader 5 et son réseau d'agents peuvent être utilisés pour des calculs mathématiques massifs.

C'est un très bon résultat. Maintenant, l'optimiseur est vraiment plus ou moins adapté aux tâches d'optimisation (liées ou non à la négociation). Les résultats seront encore meilleurs si le nombre de passes est réduit à 2 ou 3 milliers pour cette tâche spécifique avec les paramètres GA de l'optimiseur par défaut, mais pour cela vous devez afficher les paramètres GA pour que l'utilisateur puisse y accéder (il sera possible de réduire le nombre de passes à 500-900 si l'utilisateur le souhaite).

Il reste un problème lié à la limitation de l'espace de recherche. Une proposition d'optimisation correspondante a été faite dans servicedesk.

 
joo:

C'est un très bon résultat. Maintenant, l'optimiseur est vraiment plus ou moins adapté aux tâches d'optimisation (qu'elles soient directement liées à la négociation ou non). Les résultats seraient encore meilleurs si le nombre de passes était réduit à 2-3 mille pour cette tâche spécifique avec les paramètres GA par défaut de l'optimiseur, mais pour cela vous devez mettre les paramètres GA à la disposition de l'utilisateur (il sera possible de réduire le nombre de passes à 500-900 si l'utilisateur le souhaite).

Ilreste un problème lié à la limitation de l'espace de recherche. Une proposition d'optimisation correspondante a été faite dans le bureau de service.

Et la solution à ce problème est principalement liée à ce problème :

Si le dépassement de la passe d'optimisation se produit déjà avec 4 paramètres, alors parler d'augmenter le nombre de paramètres plus que ce qui est autorisé maintenant (64) n'est pas encore approprié.

 
Urain:

Et la solution à ce problème est avant tout liée à ce problème :

Si le dépassement d'optimisation se produit déjà sur 4 paramètres, alors parler d'augmenter le nombre de paramètres plus que ce qui est autorisé maintenant (64) n'est pas encore approprié.

Bien sûr. En gros, l'espace de recherche est P=n*step, où n-nombre de paramètres à optimiser et step-step du paramètre. En même temps, P doit être inférieur à Pmax (espace de recherche maximal possible, limité par les caractéristiques du codage binaire du chromosome). Par conséquent, l'une des restrictions introduites artificiellement (par exemple, vous pouvez fixer une limite de 10000 paramètres, mais alors le pas sera plus que nécessaire pour résoudre la plupart des problèmes d'optimisation), afin que P ne dépasse pas Pmax, a été introduite une restriction sur n.

Les réflexions à ce sujet sont exprimées dans la proposition d'optimiseur dans servicedesk.


PS Avec la croissance des réseaux d'agents à distance, le problème du nombre élevé d'exécutions est en train de disparaître. Mais, bien sûr, seulement si les limitations du codage binaire des chromosomes sont supprimées (lire : passer au codage des chromosomes avec des nombres réels).

 
joo:

Bien sûr. En gros, l'espace de recherche est P=n*step, où n-nombre de paramètres à optimiser et step-step du paramètre. Ainsi, P doit être inférieur à Pmax (espace de recherche maximal possible, limité par les caractéristiques du codage binaire du chromosome). Par conséquent, une des restrictions, artificiellement introduite (par exemple, vous pouvez faire une limite de 10000 paramètres, mais alors l'étape sera plus que nécessaire pour résoudre la plupart des problèmes d'optimisation), que P ne dépasserait pas Pmax, a été introduite une limite sur n.

Des réflexions à ce sujet sont présentées dans la proposition d'optimiseur dans Service Desk.


PS Au fur et à mesure que les réseaux d'agents distants se développent, le problème du grand nombre d'exécutions disparaît. Mais bien sûr, seulement si les restrictions du codage binaire des chromosomes sont supprimées (lire : passer au codage des chromosomes avec des nombres réels).

Légèrement erroné, le nombre correct de variantes est P=step_0*step_1*...*step_n

ce qui, si la taille du pas est égale, donne P=step^n

 
Urain:

Légèrement erroné, le nombre correct de choix est P=step_0*step_1*...*step_n

ce qui, si la taille du pas est égale, donne P=step^n

Eh bien, oui, vous avez raison, je dis simplement - en gros, pour être plus clair et plus évident, ce qui dépend de quoi.
 
Renat:

Dans les dernières versions, nous avons complètement éliminé les frais généraux du système au démarrage des tâches, les faisant passer de près de 2000 ms à zéro.

Fantastique ! Ah, combien de temps perdu durant l'été sur l'optimisation...

Commençons par le commencement. J'ai effectué le test de joo sur la version actuelle et sur la version 319 (02 Sep 2010). Résultats :

2010 12/229 15:49:18 Le testeur a réussi en 2 minutes 41 secondes
2010.12.29 15:49:18 L'optimisation du testeur s'est terminée sur la passe 15360 (sur 100000020000001)
2010.12.29 15:49:18 Le cache de résultat du testeur a été utilisé 7265 fois
2010.12.29 15:49:13 La génétique des testeurs est terminée
2010.12.29 17:10:59 Optimisation du testeur réussie en 1 heure 17 minutes 34 secondes
2010.12.29 17:10:59 L'optimisation génétique du testeur s'est terminée sur la passe 18176 (sur 100000020000001)
2010.12.29 17:10:59 Le cache des résultats du testeur a été utilisé 10582 fois
2010.12.29 17:10:52 La génétique du testeur est terminée

Je ne sais même pas si je dois féliciter ou remercier. Merci !

 
Urain:

Et la solution à ce problème est de s'attaquer à ce problème en premier lieu :

Si le dépassement des passes d'optimisation se produit déjà sur 4 paramètres, alors parler d'augmenter le nombre de paramètres plus que ce qui est autorisé maintenant (64) n'est pas encore approprié.

Utilisez une approche raisonnable de la recherche, mais ne tournez pas les boutons au maximum en mode "Des hommes russes cassent une tronçonneuse japonaise".

Dès que vous commencerez à appliquer l'optimisation génétique dans un travail réel, vous commencerez immédiatement à choisir des limites raisonnables.

 
Yedelkin:

Fantastique ! Eh, combien de temps perdu pendant l'été sur l'optimisation...

Dans l'ordre. Je l'ai testé sur la version actuelle et sur la 319ème version (02 Sep 2010) :

2010.12.29 15:49:18 L'optimisation du testeur a réussi en 2 minutes 41 secondes
2010.12.29 15:49:18 L'optimisation génétique du testeur s'est terminée sur la passe 15360 (sur 100000020000001)
2010.12.29 15:49:18 Le cache des résultats du testeur a été utilisé 7265 fois
2010.12.29 15:49:13 L'optimisation génétique du testeur est terminée
2010.12.29 17:10:59 L'optimisation du testeur a réussi en 1 heure 17 minutes 34 secondes
2010.12.29 17:10:59 La génétique du testeur s'est terminée sur la passe 18176 (sur 100000020000001)
2010.12.29 17:10:59 Le cache des résultats du testeur a été utilisé 10582 fois
2010.12.29 17:10:52 La génétique du testeur est terminée

Je ne sais pas si je dois féliciter ou remercier. Merci !

Notez que nous avons réduit la surcharge du système sur les phases de "synchronisation/transmission des données initiales du terminal à l'agent et réception des résultats de l'agent", ce qui a permis de gagner 1,5 à 2 secondes par exécution. Il n'y avait pas d'accélération des calculs dans la langue elle-même.

C'est-à-dire que l'effet le plus grave que cela a est sur les calculs à grande vitesse, où le calcul prend un temps proche de zéro. Pour les calculs massifs, les économies ne sont pas aussi prononcées. Bien qu'une économie de 2 secondes par 10 000 passages donne 20 000 sec = 333 minutes = 5,5 heures.

 
Renat:
Ce n'est pas le cas.

J'ai remarqué que cela a un effet. J'ai exécuté l'EA en semaine et je l'ai exécuté avec un spread étendu maintenant, le résultat est très différent, le spread est d'environ 4 pips (quatre chiffres) sur Eurobuck maintenant. Il y a donc un blocage du spread le week-end dans mt5 aussi, donc je ne veux pas l'exécuter le week-end, car l'optimisation ne sera pas correcte. Je peux même le voir visuellement dans mt4 où un EA a été optimisé depuis lundi et la courbe des résultats a baissé depuis le week-end ; cela prouve que le spread affecte les résultats de l'optimisation, ils sont devenus plus mauvais.