Automatiser la recherche de stratégies. - page 3

Nouveau commentaire
 
Aliaksandr Hryshyn:

Il y a en effet beaucoup de petites choses.

J'essaie de créer un système universel, de sorte qu'avec un minimum d'effort, il est possible d'ajouter différentes possibilités d'analyse des indicateurs, des chandeliers, etc. Chaque fonction contient des informations sur les données avec lesquelles elle peut travailler et sur les données qui seront produites. Les indicateurs seront également décrits, ainsi que le type de données qu'ils fournissent. Les données sont divisées en types, à la fois simples et complexes, par exemple {double} et {int,double}. Elles sont divisées en catégories, pour le même exemple "prix" et "positions sur le graphique", un autre exemple : "ligne droite" (peut être utilisée pour définir des canaux), etc. Elles sont classées par "type d'échelle", par exemple "constante" (paramètre de la stratégie), "indice" (il y a un minimum et un maximum), "ratio" (il n'y a qu'un seul point de référence, par exemple le prix, le volume), etc. Il est nécessaire de modifier la stratégie de manière cohérente, il y a une telle nuance, la modification à un endroit peut affecter les conditions de modification à un autre endroit.

C'est vrai... Pour réduire le nombre de combinaisons de la recherche et utiliser les restrictions ci-dessus (type, échelle, catégorie), il suffira pour l'instant de modifications ponctuelles (ajout/suppression d'une/de quelques fonctions).

"Si l'on considère que la recombinaison est également spontanée, mais qu'il s'agit de solutions toutes faites (cette idée m'est venue à l'esprit), il est difficile d'imaginer comment elle peut être réalisée. Un groupe de fonctions combinées aura très probablement plus de connexions avec le "monde extérieur" qu'une fonction unique, de sorte qu'il y aura moins d'occasions de tout coincer. L'algorithme devient très compliqué, laissons-le en suspens jusqu'à des temps meilleurs)).

Permettez-moi de clarifier ma pensée. Pour réduire le nombre de variantes et faire en sorte que les modifications apportées à l'une d'entre elles n'affectent pas les autres blocs, il faudrait que le système soit encore plus universel. Le problème est que les mêmes tâches peuvent être accomplies par différentes méthodes et que, souvent, il n'est pas évident de déterminer à l'avance laquelle est la meilleure. Par exemple, nous avons défini une tâche universelle appelée TRANSFORMATION. Il existe une douzaine d'oscillateurs qui définissent chacun à leur manière cette sursollicitation. Supposons que dans le script de l'oscillateur, nous ayons défini la tâche d'essayer TOUS les indicateurs ou toutes les méthodes. Nous devons ensuite standardiser l'interaction de ces blocs avec le reste du code. Disons que nous avons choisi comme norme d'interaction les pourcentages du haut. Le générateur insère séquentiellement dans le code un bloc appelé Oversold1, trouve les variables à tester dans ce bloc particulier, exécute un volkin-forward et se souvient des résultats du test. Ensuite, il prépare une nouvelle version de l'Expert Advisor, déjà avec le bloc Oversold 2, qui donne également des pourcentages, malgré le fait que l'indicateur original montre des nombres entiers, et même avec un signe différent de zéro, etc. À la fin des tests, il abandonne le bloc le plus performant et passe à une autre tâche.

En même temps, il n'est pas nécessaire de préparer autant de blocs au départ, 2 ou 3 blocs suffisent. L'essentiel est d'établir une interaction.

Il en va de même pour les dépendances. Il y a A, B, C. D'abord, si A est plus grand que B, alors C est vrai. Ensuite, si B est plus grand que A, et ainsi de suite.

Ensuite, on peut passer à des interactions plus complexes.

 

"Afin de réduire le nombre d'options et de faire en sorte que la modification de l'une d'entre elles n'affecte pas les autres, les blocs devraient être plus polyvalents. => "Disons que nous avons choisi la norme d'interaction - les pourcentages du sommet". - Je comprends votre point de vue)). Il s'agit de ramener les indicateurs à une vue unique, c'est-à-dire de les prétraiter. Dans mon système, tout est trop formalisé, j'aimerais tout garder, je travaille déjà à la mise en place de choses comme l'échelle, la catégorie, j'ai déjà compris comment faire, il y a vraiment une connexion de certains blocs qui affecte la connexion des blocs à d'autres endroits. La normalisation des indicateurs passe par la description de l'indicateur lui-même et, en fonction de celle-ci, certains blocs seront automatiquement connectés. Un des blocs peut facilement être le calcul du pourcentage d'une valeur par rapport à une autre, seulement ces valeurs doivent avoir une connexion entre elles, qui sera contrôlée, par exemple :

  1. Pourcentage( Open[0] , Open[3] )
  2. Pourcentage(Open[0], Alligator[3])
  3. Pourcentage(Volume[0], Alligator[3])

Les options 1 et 3 sont bonnes et logiques, mais l'option 3 n'a pas de sens.

Les indices seront également calculés, par exemple Open[ Max_on_position(iAC,0,30) ] ]

 
Youri Tarshecki:

En même temps, il n'est pas nécessaire de préparer autant de blocs pour commencer, 2 ou 3 blocs suffisent. L'essentiel est d'établir une interaction.

Il en va de même pour les dépendances. Il y a A, B, C. On vérifie d'abord si A est plus grand que B, puis C est vrai, puis si B est plus grand que A, et ainsi de suite.

Ensuite, on peut passer à des interactions plus complexes.

C'est déjà le cas.

Il est mis en œuvre de la manière suivante :

  1. il existe des types de base int,double,bool
  2. les types complexes sont créés à partir des types de base (vous pouvez les ajouter), par exemple (int,double) - coordonnées sur le graphique, (x,b) - coefficients de l'équation de la droite, (a,b,c,d) - support pour jusqu'à 4 valeurs.
  3. les indicateurs sont représentés comme un ensemble de types complexes avec un élément
  4. les constantes sont représentées comme des types complexes ; ce sont les paramètres de la stratégie qui sont optimisés
  5. les fonctions reçoivent certains types complexes de variables en entrée, leur nombre n'est pas limité, la sortie est également constituée de types complexes.
  6. Les fonctions ne se soucient pas de l'origine de ces données, l'essentiel étant qu'il y ait une correspondance entre les types.
  7. tous les ordres disponibles dans mql4 sont pris en charge (6 pièces)
  8. la stratégie ne définit qu'un seul type d'ordre (achat ou vente ou achat_stop ou...)
  9. pour les ordres non en cours, il y a 4 noeuds en haut du graphe : condition d'entrée sur le marché, condition de sortie, tp et sl.
  10. Les blocs (fonctions/nœuds du graphique) peuvent prendre des paramètres d'entrée provenant d'indicateurs, de constantes, d'autres nœuds, il est permis que plusieurs autres nœuds prennent des données comme paramètres d'entrée à partir du résultat d'un nœud, il n'y a pas de restrictions, à l'exception du fait qu'il est impossible d'autoriser des cycles dans le graphique.
  11. Ensuite, le graphe est traduit en un code séquentiel, et ce code sera envoyé à l'Expert Advisor pour exécution, rien n'a besoin d'être compilé dans MQL.
Voici un exemple de code :

#define
 symbol          GBPUSD;
period          60;
repeat_signal_skip      True;
stop_level              60;
trade           op_buy;
max_shift               13;
stack           4;
const           9;
cache           1;
#data
{True},{-1.26761795},{4.67108999},
{2.08088665},{-0.33782435},{22},
{1.63150050},{-11},{-0.22006371};
#program
 push    [0];
push    [1];
push    [2];
call    F_plus_d;
push    [3];
push    [4];
call    F_plus_d;
push    [5];
get     .Ichimoku_2;
call    F_plus_d;
push    [6];
call    F_minus_d;
save    [0];
push    [7];
get     .Open;
call    F_plus_d;
call    F_less;
load    [0];
push    [8];
#end

Tout n'est pas encore fait, toutes les informations nécessaires ne sont pas dans le code, le code est exécuté correctement du point de vue du contrôle des types, les expressions sans signification ne sont pas encore prises en compte.

Seuls des types simples sont utilisés dans le code.

 

Je suppose que les stratégies peuvent être transmises via le protocole HTTP, MQL a la possibilité de recevoir des stratégies de cette manière.

Je souhaite que tout soit entièrement automatisé, recherche de stratégies, création de portefeuilles de stratégies, transfert vers l'Expert Advisor, etc.

Une partie du système dans MQL est prête à 90% et fonctionne avec un grand nombre de stratégies (contrôle de position, risques, gestion des erreurs, etc.)

Il reste encore beaucoup de travail à faire.

 
Yuriy Asaulenko:
Si vous cherchez une stratégie, ce n'est pas plus facile. Je ne sais pas ce qu'il en est du reste, je n'y ai pas réfléchi. Cependant, toute modélisation est plus facile dans des environnements spéciaux, pas dans la TA. MT est un produit final, il n'a pas été créé pour la recherche et ne s'y prête guère.
Je suis d'accord, j'ai initialement modélisé l'idée dans Matlab moi-même. Cependant, le testeur MT est une boîte noire.
 
Aliaksandr Hryshyn:
Voici un autre exemple d'expression dépourvue de sens : =High>(Open-Close), elle ne passera pas non plus.

Expliquez pourquoi elle n'a pas de sens. En réalité, je l'écrirais comme ceci

=High>MathAbs(Open-Close)

ю

 

Aliaksandr Hryshyn:

le graphique est ensuite traduit en un code série, et ce code sera envoyé à l'Expert Advisor pour exécution, rien ne doit être compilé dans MQL.


Comment, s'il vous plaît expliquer ?
 

Il retournera toujours vrai)).

(Open-Close) sera toujours inférieur à (High)

 
Alexey Volchanskiy:

Expliquez comment, s'il vous plaît.
Qu'est-ce qui est diffusé ou exécuté ?
 
Aliaksandr Hryshyn:

Il retournera toujours vrai)).

(Open-Close) sera toujours inférieur à (High)

Freinage ))))))))))
123456
Nouveau commentaire