Questions sur l'assistant MQL5 et la bibliothèque standard de classes de trading - page 11

Nouveau commentaire
 
Reshetov:

Trois questions :

  1. Comment faire pour que le module de signal ne fonctionne que sur les prix d'ouverture et non sur chaque tick ?
  2. Comment puis-je obtenir les valeurs de vote du module de signal dans le module de suivi de position ? Vous devez chaluter sur un signal déjà calculé et ne pas inventer un autre module de signal à suivre.
  3. Comment obtenir les valeurs de vote du module d'alarme dans le module de gestion de l'argent et des risques ? Vous devez ouvrir les volumes en fonction des signaux de trading déjà calculés, et non pas composer un autre module de signaux pour le calcul des volumes.

En théorie, nous pouvons bien sûr construire l'EA à l'aide de l'assistant, puis ajouter toutes ces fonctionnalités manuellement au code. Mais il est souhaitable que tout cela soit implémenté sous la forme de méthodes standard, c'est-à-dire pour les nuls qui veulent utiliser l'assistant, afin qu'ils n'aient pas à entrer dans le code et à le modifier, par exemple, au cas où ils voudraient remplacer un module de signal par un autre.

Vous répondez à toutes vos propres questions : "... construire l'EA à l'aide d'un assistant, puis ... manuellement ...". Il n'y a pas encore d'autres options. L'assistant, très probablement, ne sera pas développé dans un avenir proche. Les classes de la bibliothèque standard ne sont pas un dogme, mais une tentative de fournir un ensemble de solutions typiques (à mon avis). Hériter (pour l'utiliser dans l'assistant), surcharger les méthodes, ajouter les vôtres. Et vous serez "heureux"...
 
uncleVic:
Vous avez répondu vous-même à toutes vos questions : "... ...construire l'EA à l'aide d'un assistant et ensuite... manuellement ...". Il n'y a pas encore d'autres options. L'assistant, très probablement, ne sera pas développé dans un avenir proche.

Il est dommage qu'une si bonne entreprise soit abandonnée dans un coin lointain.

S'il avait été mis à jour, beaucoup de choses auraient pu être faites, c'est-à-dire que nous aurions pu créer des modules prêts à l'emploi à partir desquels les mannequins et autres utilisateurs pourraient assembler divers EA prêts à l'emploi sans devoir passer par les codes. Mais dans ce cas, nous obtenons le même désordre qu'avec la mql4 algorithmique, c'est-à-dire que vous prenez un algorithme, entrez dans le code et l'utilisez manuellement. Encore une fois, le principe de la POO est violé. Par exemple, si vous voulez remplacer un module par un autre, vous devrez retourner dans le code et tout modifier manuellement à nouveau. Vous obtenez beaucoup d'absurdités, car le seul fait de "ramper" dans les codes, afin de comprendre au moins où et quoi modifier, vous ferait perdre beaucoup de temps.

C'était un bon début. C'est dommage. J'ai créé un module de signal hier, mais je ne sais toujours pas comment faire fonctionner l'ensemble de l'EA sans passer par le code source à chaque fois. Je viens d'insérer le module, j'ai ajouté la gestion des positions, la gestion de l'argent et la gestion des risques, et tout fonctionne. Mais non, ça ne marchera pas. Si un utilisateur construit un EA en utilisant l'assistant, il ne fonctionnera pas. Il devra écrire des tas d'instructions pour savoir où regarder dans le code et ce qu'il faut changer. Sans compter que je dois encore m'occuper de tout cela moi-même avant de rédiger une instruction.

Il ne reste donc plus aux utilisateurs qu'à apprendre mql5, OpenCL, etc. pour gérer l'autotrading. Sinon, ils n'auront pas de chance.

Eh bien, puisque ce projet a été abandonné, je vais maintenant réfléchir dans une autre direction.

 
Reshetov:

C'est dommage qu'une si bonne entreprise soit abandonnée dans un coin lointain.

Espérons qu'il n'est pas abandonné, mais mis de côté. J'ai moi-même de nombreuses réflexions intéressantes sur le développement du Maître. Mais...
 
uncleVic:
Espérons qu'il ne soit pas abandonné mais reporté. J'ai moi-même beaucoup de réflexions intéressantes sur le développement du Sorcier. Mais...

L'espoir meurt en dernier (c) proverbe populaire

A la première question, c'est à dire comment tester le module de signal en ouvrant les prix et en négociant par ticks, j'ai trouvé une solution pour ne pas avoir à rentrer dans les codes, et même mieux que celle généralement admise.

Je n'ai pas encore compris comment lire les indications du module de signaux dans les modules de gestion des positions et de gestion des actions et des risques. J'ai cherché le code source et j'ai regardé autour de moi. Le module signal obtient ses résultats par la méthode direction(), c'est-à-dire qu'il me suffit d'adresser une instance de cette même classe de module dans les modules de gestion des positions et de gestion des capitaux et des risques et d'appeler cette même méthode pour lire ses valeurs. La façon dont cela peut être fait sans modifier le code n'est pas encore claire.

 
Reshetov:

L'espoir est éternel (c) proverbe populaire

A la première question, c'est à dire comment tester le module de signal en ouvrant les prix et en négociant par ticks, j'ai trouvé une solution pour ne pas avoir à rentrer dans les codes, et même mieux que celle généralement admise.

Et je n'arrive pas à comprendre comment lire les lectures du module signal dans les modules gestion des positions et gestion des actions et des risques, sans creuser les codes. J'ai cherché le code source et fait mes devoirs. Le module signal obtient ses résultats par la méthode direction(), c'est-à-dire qu'il me suffit d'adresser une instance de cette même classe de module dans les modules de gestion des positions et de gestion des actions et des risques et d'appeler cette même méthode pour lire ses valeurs. La façon dont cela peut être fait sans modifier le code n'est pas encore claire.

Sans changer les codes, cela ne fonctionnera probablement pas.

 
uncleVic:

Ne pas changer les codes ne fonctionnera probablement pas.

Tout n'est pas encore perdu. Vous pouvez créer des classes héritées de CExpert, CExpertMoneu et CExpertTrailing et leur ajouter les méthodes nécessaires pour accéder à une instance de la classe du module de signalisation. Mais il y a un problème ici aussi, car l'assistant écrit dans l'EA créé #include <Expert\Expert.mqh> et non son descendant.

Nous devons encore y réfléchir.

Si les développeurs avaient deviné dès le départ qu'un module de signaux peut être utilisé pour tous les autres modules comme le principal et que des signaux supplémentaires (comme dans cette version de l'assistant) peuvent être ajoutés aux modules de support de position et de gestion des actions et des risques, les codes auraient été plus faciles. Mais dans notre cas, chaque module nécessite de spécifier des conditions supplémentaires pour les signaux et donc ils ont besoin de paramètres externes supplémentaires, ce qui résulte en un tel monstre avec beaucoup de paramètres à optimiser. Sans oublier que les signaux d'un module peuvent entrer en conflit, c'est-à-dire qu'un module de signal peut ouvrir une position et un module auxiliaire la fermer au prochain tick, si les conditions d'entrée et de sortie du marché sont contradictoires.

 
Reshetov:

Tout n'est pas encore perdu. Après tout, vous pouvez créer des classes héritées de CExpert, CExpertMoneu et CExpertTrailing et leur ajouter les méthodes nécessaires d'accès à une instance de la classe du module de signal. Mais il y a un problème ici aussi, car l'assistant écrit dans l'EA créé #include <Expert\Expert.mqh> et non son descendant.

Nous n'y avons pas encore réfléchi.

Si les développeurs avaient deviné dès le départ qu'un module de signaux peut être utilisé pour tous les autres modules comme le principal et que des signaux supplémentaires (comme dans cette version de l'assistant) peuvent être ajoutés aux modules de support de position et de gestion des actions et des risques et qu'ils l'avaient prévu dans les codes, ce serait beaucoup plus facile. Mais dans notre cas, chaque module nécessite de spécifier des conditions supplémentaires pour les signaux et donc ils ont besoin de paramètres externes supplémentaires, ce qui résulte en un tel monstre avec beaucoup de paramètres à optimiser. Sans mentionner le fait que les signaux d'un module peuvent entrer en conflit, c'est-à-dire qu'un module de signal peut ouvrir une position et un module auxiliaire la fermer au prochain tick, si les conditions d'entrée et de sortie du marché sont contradictoires.



C'est comme ça que c'est conçu. L'assistant crée le "poisson" de l'EA. Plus loin :

  • Le remplacement de l'inclusion ne pose aucun problème ;
  • le signal principal est intentionnellement créé à l'extérieur (pour la commodité de la substitution) ;
  • ajouter quelques ints et définir des appels de méthode ?
 
uncleVic:

C'est ainsi que cela a été prévu. Le maître crée le "poisson" du conseiller. Suivant :

  • Le remplacement de l'inline ne pose aucun problème ;
  • le signal principal est intentionnellement créé à l'extérieur (pour faciliter la substitution) ;
  • ajouter des intuts et des appels de méthode de réglage ?


C'est ce qui est laid, des choses comme :

  1. L'accès aux méthodes des classes de modules inclus dans le système de négociation est refusé même pour la lecture, ce qui exclut complètement la possibilité de coordonner leur travail.
  2. Les modules de signaux peuvent facilement entrer en conflit avec les modules de suivi de position, car ils ont des signaux différents, et une incompatibilité ne peut donc être exclue.
  3. Différents signaux dans les modules, et donc ils ont tous des paramètres séparés, ce qui résulte en non pas quelques, mais de nombreux paramètres d'entrée pour un EA. Plus il y a de paramètres différents, plus la probabilité de s'adapter à l'histoire est élevée.
  4. Après l'opération de l'assistant, il est parfois nécessaire de parcourir les sources afin de résoudre les problèmes. Pour l'utilisateur final qui n'est pas familier avec la programmation, il n'est pas du tout adapté, car il a besoin d'un système prêt à l'emploi. Ces confusions créent également des problèmes pour un programmeur, car il est beaucoup plus facile de travailler avec son propre code qu'avec un code empilé par un assistant. Une difficulté supplémentaire est que les classes sont héritées, c'est-à-dire que la cause d'un malentendu peut rarement être trouvée au niveau des descendants, mais qu'il faut regarder plus profondément dans les classes mères.

Nous voulions le meilleur. Il s'avère que c'est toujours la même chose (c) Tchernomyrdine

En général, la plupart des malentendus peuvent être corrigés, mais cela doit être fait au niveau de la classe mère racine, puis les classes corrigées peuvent être distribuées par des mises à jour de la plate-forme. C'est-à-dire que vous devez ouvrir l'accès à la méthode Direction() du module de signal à partir des modules de support de position et de gestion des actions et des risques. En effet, si les développeurs de modules individuels modifient le code source des classes parentes, il en résulte une incompatibilité du code source et les modules créés ne fonctionneront pas sur d'autres ordinateurs. Si les développeurs de modules créent des classes parentes avec des méthodes surchargées, l'incompatibilité sera toujours au niveau du maître, parce que ce dernier écrit ses propres inludes, et, par conséquent, les utilisateurs finaux doivent écrire à nouveau des instructions, et ils ne voudront guère entrer dans les sources, et s'ils le font, alors erreur dans un seul symbole ou ailleurs, etc....

 
Reshetov:

C'est le problème, parce que dès le début, il y a des choses qui n'ont pas été prises en compte :

  1. Les méthodes de classe des modules inclus dans le système de négociation ne sont pas accessibles, même en lecture, ce qui exclut totalement la possibilité de coordonner leur travail.
  2. Les modules de signaux peuvent facilement entrer en conflit avec les modules de suivi de position, car ils ont des signaux différents et une incompatibilité ne peut donc être exclue.
  3. Différents signaux dans les modules, et donc ils ont tous des paramètres séparés, ce qui résulte en non pas quelques, mais de nombreux paramètres d'entrée pour l'EA. Plus il y a de paramètres différents, plus la probabilité de s'adapter à l'histoire est élevée.
  4. Après l'opération de l'assistant, il est parfois nécessaire de parcourir les sources afin de résoudre les problèmes. Pour l'utilisateur final qui n'est pas familier avec la programmation, il n'est pas du tout adapté, car il a besoin d'un système prêt à l'emploi. Ces confusions créent également des problèmes pour un programmeur, car il est beaucoup plus facile de travailler avec son propre code qu'avec un code empilé par un assistant. Une difficulté supplémentaire est que les classes sont héritées, c'est-à-dire que la cause d'un malentendu peut rarement être trouvée au niveau des descendants, mais qu'il faut regarder plus profondément dans les classes mères.

Nous voulions le meilleur. Il s'avère que c'est toujours la même chose (c) Tchernomyrdine

En général, la plupart des malentendus peuvent être corrigés, mais il est souhaitable de le faire au niveau de la classe mère racine et de distribuer ensuite les classes corrigées par le biais de mises à jour. En effet, si le code source des classes parentales est corrigé par les développeurs de modules, il en résultera une incompatibilité du code source et les modules créés ne fonctionneront pas sur d'autres ordinateurs. Si le développeur crée des classes parentes avec des méthodes surchargées, alors l'incompatibilité est déjà au niveau du maître, parce qu'il écrit ses propres inclusions, et doit donc à nouveau écrire des instructions aux utilisateurs finaux, et il est peu probable qu'ils veuillent entrer dans le code source, et s'ils y entrent, alors l'erreur dans un seul caractère ou ailleurs, et ainsi de suite.

Faisons des suggestions précises. Nous les prendrons en considération.
 
uncleVic:
Laissez-nous vous donner quelques suggestions. Nous allons les examiner.

Jusqu'à présent, il n'existe qu'une seule chose qui réponde aux inconvénients ci-dessus :

Ouvrir l'accès à la lecture des valeurs retournées par la méthode Direction() du module signal à partir des modules de gestion des positions et de gestion des capitaux et des risques.

Ajoutez une méthode supplémentaire, par exemple, avec l'identifiant double getMainSingnal(), qui fait référence à une instance de la classe du module de signaux et renvoie le résultat de la méthode Direction() du module de signaux. Comme cet échange d'informations a lieu en mode lecture seule, la sécurité ne sera en aucun cas rompue.

Pour ce faire

  1. Allouer certains champs dans les classes CExpertMoney et CExpertTrailing pour stocker une instance de CExpertSignal, c'est-à-dire le module principal des signaux.
  2. Une instance de CExpertSignal, c'est-à-dire le module de signaux, doit être transmise aux modules de gestion des positions et de gestion des capitaux et des risques lors de l'initialisation des instances de ces modules et stockée dans les champs spécifiés à l'étape 1. Évidemment, avant de faire cela, nous devons également vérifier (nous assurer) qu'il existe déjà une instance de la classe du module de signal, c'est-à-dire qu'elle a été créée.
  3. Créer dans les classes CExpertMoney et CExpertTrailing des méthodes supplémentaires, avec l'identifiant double getMainSingnal(), qui s'adressent à une instance de la classe du module signaux, stockée dans les champs correspondants de ces classes et renvoient le résultat de la méthode Direction() du module signaux.

P.S. La classe CExpert a une référence à une instance de la classe module de signal.

CExpertSignal    *m_signal;                   // trading signals object
Vous devez créer des champs analogues pour les classes CExpertMoney et CExpertTrailing et leur passer la même valeur du champ mentionné ci-dessus dans la classe CExpert pendant l'initialisation.
1...456789101112131415
Nouveau commentaire