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

[Renat Fatkhullin]

En bref :

• La suffisance raisonnable consiste à s'inscrire dans un champ de recherche de 2 à la puissance 64.
• Un comportement raisonnable consiste à préestimer le champ de recherche au lieu de pousser au maximum toutes les variables à rechercher.

Rashid, il est peu probable que quelqu'un ose faire une énumération directe. Un optimiseur génétique 2^64 vérifiera facilement, mais cela ne signifie pas que nous devons exposer des régions de recherche illimitées. Après tout, nous devons générer des gènes pour ces régions et ensuite les manipuler.

[Sergey Chalyshev]

Rosh:

OK, faisons le calcul. Supposons qu'une passe dans le testeur prenne 1 seconde, alors le nombre de passes est 2^64-1 divisé par 60 et nous obtenons le temps d'optimisation en minutes : 18 446 744 073 709 551 615/60.

Ensuite, divisez ce temps par 8 (8 cœurs sur l'ordinateur) et obtenez le temps d'optimisation avec ce nombre de passes sur un ordinateur à 8 cœurs. Combien cela prendra-t-il en heures ou en jours ?

Ne comptez pas, je ne parle pas d'une simple énumération. Laissez l'algorithme génétique déterminer lui-même combien il en a besoin.

Si vous le comparez au cerveau humain, selon les scientifiques, le cerveau contient environ 10^10 neurones et chacun a environ 10^4 connexions synaptiques.

C'est ce à quoi nous aspirons tous, en créant des programmes de plus en plus avancés.

Pour quoi l'informatique dématérialisée a-t-elle été conçue ? Grâce à cela, les utilisateurs ne sont pas limités à un seul ordinateur, ce dont nous les remercions vivement.

[Sergey Chalyshev]

Renat:

Pour faire une longue histoire courte :

• La suffisance raisonnable consiste à s'inscrire dans un champ de recherche de 2 à la puissance 64.
• Un comportement raisonnable consiste à préestimer le champ de recherche au lieu de pousser au maximum toutes les variables à rechercher.

Rashid, il est peu probable que quelqu'un ose faire un simple dépassement. Un optimiseur génétique 2^64 vérifiera facilement, mais cela ne signifie pas que vous devez exposer des domaines de recherche illimités. Après tout, nous devons générer des gènes pour ces régions et ensuite les manipuler.

Ce qui est 2 sur 64 est un problème tiré par les cheveux.

Dans un algorithme génétique, il n'est pas nécessaire de conserver les pires résultats ?

Qu'est-ce qui vous empêche de tordre toutes les variables au maximum ?

Je n'arrive pas à comprendre quel est le lien entre les gènes et 2^64 ?

[ddd06]

Néanmoins, il peut s'avérer utile de rechercher dans un grand nombre de variables (par exemple, un réseau neuronal) et cette limitation n'est pas bonne.

J'espère donc être libéré des contraintes))

[Andrey Dik]

Le testeur de stratégie semble utiliser GA avec un codage binaire des chromosomes.

Voici une citation:

"Cependant, la représentation binaire des chromosomes entraîne certaines difficultés lors de la recherche dans des espaces continus de grande dimension, et lorsqu'une grande précision est requise, une technique spéciale est utilisée, basée sur le fait que l'intervalle entier des valeurs admissibles d'une caractéristique [ai,bi] est divisé en sections avec la précision requise. La précision requise p est définie par l'expression :

où N est le nombre de bits pour coder une chaîne de bits.

Cette formule montre que p dépend fortement de N, c'est-à-dire que la précision de la représentation est déterminée par le nombre de bits utilisés pour coder un chromosome. Par conséquent, lorsque N augmente, l'espace de recherche s'étend et devient énorme. Un exemple de livre bien connu : 100 variables variant dans l'intervalle [-500 ; 500], il faut trouver un extremum à six décimales près. Dans ce cas, en utilisant GA avec codage binaire, la longueur de la chaîne serait de 3000 éléments et l'espace de recherche serait d'environ¹⁰¹⁰⁰⁰ chromosomes."

Par conséquent, même un réseau neuronal de taille relativement petite dans l'optimiseur standard, lorsqu'il est limité à 64 paramètres à optimiser, ne peut être formé. Il y a un autre inconvénient - il est très long de remplir manuellement les paramètres des variables optimisables s'il y en a beaucoup. C'est pourquoi j'ai déjà suggéré que vous pouvez spécifier des tableaux avec des paramètres optimisables de manière programmatique.

Mais il y a de bonnes nouvelles. Tout ce qui manque dans le testeur et le terminal peut être mis en œuvre en utilisant les moyens natifs de MQL5. Plus tard, je posterai les résultats de quelques tests d'optimisation en utilisant le testeur et le code du programme.

[Andrey Dik]

Cependant, je n'ai jamais attendu les résultats du testeur sur la tâche de test (je veux dire, attendre est paresseux).

Mais tout le monde peut faire les tests lui-même. Pour cela, vous pouvez prendre le premier exemple de l'article. N'oubliez pas de définir le mode d'optimisation - recherche des maxima (pour pouvoir comparer avec l'optimiseur standard où seuls les maxima sont disponibles).

Écrivons un conseiller expert simple, encore plus simple qu'un navet vert, qui ne fait rien d'autre que de calculer la fonction de test de l'utilisateur :

//+------------------------------------------------------------------+
//|                                                  Test expert.mq5 |
//|                                      Copyright 2010, JQS aka Joo |
//|                              https://www.mql5.com/ru/users/joo |
//+------------------------------------------------------------------+
#property copyright "Copyright 2010, JQS aka Joo"
#property link      "https://www.mql5.com/ru/users/joo"
#property version   "1.00"
//--- input parameters
input double   x1=0.0;
input double   x2=0.0;
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit()
  {
//---

//---
   return(0);
  }
//+------------------------------------------------------------------+
//| Expert deinitialization function                                 |
//+------------------------------------------------------------------+
void OnDeinit(const int reason)
  {
//---

  }
//+------------------------------------------------------------------+
//| Expert tick function                                             |
//+------------------------------------------------------------------+
void OnTick()
  {

  }
//+------------------------------------------------------------------+

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)
    );
  }
//+------------------------------------------------------------------+

Les paramètres de la fenêtre du testeur sont les suivants :

Dans l'onglet "Paramètres d'entrée", procédez comme suit :

Et allez-y.

Les conclusions approximatives sont les suivantes :

1) L'optimiseur dans le testeur est 10 à 100 fois plus lent (cela a fonctionné pour moi, même si l'optimisation dans le testeur était effectuée sur deux cœurs de processeur, alors que l'optimisation logicielle était effectuée sur un seul cœur). Il est fort probable qu'une différence aussi monstrueuse soit due au fait que le testeur doit écrire des journaux, afficher des informations sur l'écran, etc., en plus des calculs directs de la FF, c'est-à-dire qu'il a un "freinage forcé" par opposition à une optimisation logicielle.

2) Il est impossible d'utiliser plus de 64 paramètres optimisables dans le testeur (et dans l'assistant pour la création de conseillers experts, il est limité à 60 paramètres), il est donc impossible d'entraîner des réseaux neuronaux d'une taille significative.

Il faut soit écrire soi-même des substituts de test (MQL5 le permet, c'est une excellente "canne à pêche" mais pas un "poisson"), soit attendre que l'algorithme génétique binaire du testeur soit remplacé par un algorithme continu et que la limitation du nombre de paramètres optimisés soit supprimée. La seconde n'est pas constructive, donc la première demeure. :)

Conclusion globale : Apprenez MQL5.

PS Une bonne solution serait d'activer ou de désactiver la sortie des informations d'optimisation (journaux, graphique d'optimisation) et, encore mieux, de personnaliser les détails de la sortie afin d'augmenter les performances du testeur.

[Mr.FreeMan]

joo, ce n'est pas tout, outre l'écriture d'un testeur et d'un optimiseur pour des calculs aussi complexes, vous devez créer un distributeur de calculs, ce qui implique tous les cœurs du processeur et éventuellement la connexion d'agents distants (si vous effectuez des calculs collectifs). Premièrement, sa vitesse n'est pas comparable à celle du testeur standard - tout fonctionnera beaucoup plus lentement, et deuxièmement, pour écrire tout cela, vous devez passer beaucoup de temps et des centaines de kilo-octets de code, et tout cela à cause de quoi, exactement ?

[Mykola Demko]

Mr.FreeMan:
joo, ce n'est pas tout, outre l'écriture d'un testeur et d'un optimiseur pour des calculs aussi complexes, vous devez créer un distributeur de calculs, ce qui implique tous les cœurs du processeur et éventuellement la connexion d'agents distants (si vous effectuez des calculs collectifs). Premièrement, il n'est pas comparable au testeur standard - tout sera beaucoup plus lent, et deuxièmement, pour écrire tout cela, vous devez passer beaucoup de temps et des centaines de kilo-octets de code, et quelle est la raison ?

Le GA de joo est déjà plus rapide que le standard, et en portant le code vers CPP avec studio 10 (adapté aux processeurs multi-cœurs), la vitesse est encore 6 fois plus rapide.

[Andrey Dik]

Mr.FreeMan:
joo, ce n'est pas tout ; en plus d'écrire un testeur et un optimiseur pour de si petits calculs, il faut aussi faire un distributeur pour les calculs qui impliqueraient tous les cœurs du processeur et éventuellement connecter des agents distants (si vous voulez tenir des calculs collectifs). Premièrement, sa vitesse n'est pas comparable à celle du testeur standard - tout fonctionnera beaucoup plus lentement, et deuxièmement, pour écrire tout cela, vous devez passer beaucoup de temps et des centaines de kilo-octets de code, et tout cela à cause de quoi, exactement?

A propos du rouge, Urain a répondu.

Quant au vert, c'est une question d'argent, bien sûr. Le temps, c'est de l'argent. D'habitude, je suis lent à démarrer, mais je suis rapide (il m'a fallu plus d'un an pour développer et déboguer l'AG), et maintenant je continue à recevoir des messages de remerciement dans ma boîte de réception après la publication de l'article. :)

Je ne critique pas le testeur interne. Je ne fais qu'attirer l'attention des développeurs sur ce qui doit faire l'objet d'une attention particulière. Après tout, quelle que soit la qualité de l'optimiseur (l'optimiseur, pas le testeur), s'il est terriblement lent, tous ses avantages s'évanouissent.

[Andrey Dik]

Une idée audacieuse vient de me venir à l'esprit. Bien qu'en fait, pourquoi ne le ferait-elle pas ?

Je serai honoré d'utiliser mon UGA dans l'optimiseur MetaTrader 5 de MetaQuotes Software Corp. Il sera absolument gratuit, même si je ne refuserai pas les bonus bien sûr.

L'UGA est simple et efficace. Très flexible dans les réglages. Vous pouvez entrer trois modèles de réglages dans le testeur - "Rough", "Medium" et "Fine", et aussi afficher séparément les réglages d'Evans avec une indication "Si vous ne savez pas exactement à quoi vous servir, ne changez rien à ces réglages". Il sera alors possible de procéder à l'optimisation avec le degré de recherche de détails souhaité - de l'approximation très rapide à la recherche finale exacte des réglages optimaux des CT. Pour le moment, l'optimiseur intégré ne permet pas d'être configuré de quelque manière que ce soit.