Sujet intéressant pour beaucoup : les nouveautés de MetaTrader 4 et MQL4 - de grands changements en perspective - page 9
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
Maintenant que nous avons touché le marché, j'aimerais entendre les opinions sur un sujet...
Selon la philosophie de MQL5, les indicateurs doivent compter et les EA doivent trader.
Mais Market vend des solutions toutes faites, comme on dit, tout en un.
Pourquoi ne pas améliorer le compilateur pour que les indicateurs soient stockés dans les EA en tant que ressources ?
Sinon, nous devons transférer le code de l'indicateur vers le conseiller expert où il n'a pas d'environnement approprié. Encore une fois, le schéma "d'un indicateur à l'autre" permet de transférer le code vers le conseiller expert.
Je suis d'accord,
Je pense qu'il serait utile d'ajouter un onglet pour le marché actuel - FILES, où l'on peut mettre les sets, les instructions, etc,
Je pense qu'il serait utile d'ajouter un onglet - FICHES où l'on peut stocker les jeux, les instructions, etc.
Peut-on affiner le compilateur pour stocker les indicateurs dans les EA comme des ressources ?
Sinon, nous devons transférer le code d'un indicateur dans un conseiller expert, où il n'a pas d'environnement approprié. Encore une fois, le schéma "indicateur de l'indicateur" permet de déplacer le code vers le conseiller expert.
Voir MetaTrader 5 Client Terminal build 730 le 24 novembre 2012
8. MQL5 : Ajout du support pour le stockage des indicateurs dans les ressources EX5. Dans le même temps, les indicateurs de ressources ne seront pas en mesure de travailler avec leurs propres ressources.
Voir le communiqué de presse MetaTrader 5 Client Terminal build 730 du 24 novembre 2012.
C'est exactement ce que je fais. Et j'ai déjà écrit des classes qui peuvent passer à l'Expert Advisor un historique personnalisé (au lieu de l'historique réel du serveur). Mais l'Expert Advisor ne devrait pas utiliser les fonctions du terminal directement pour mettre en œuvre pleinement mon idée. Disons, le même OrderSend(). Il ne doit fonctionner qu'à travers un "wrapper", dont le rôle peut être merveilleusement rempli par la bibliothèque standard. Nous écrivons des classes dérivées, les intégrons dans l'Expert Advisor, et voilà - il fonctionne maintenant sur des données historiques. Si l'Expert Advisor utilise directement les fonctions du terminal, il ne sera pas en mesure d'utiliser l'historique.
Peut-être est-ce dû à mon long travail avec la bibliothèque MFC, dont j'ai été très satisfait et avec laquelle je trouve de nombreux parallèles. Je suis sûr que les développeurs de la bibliothèque standard connaissent aussi très bien les MFC.
Le principal avantage de la bibliothèque standard est le bon support de l'idéologie OOP, qui permet de passer au conseiller expert un historique personnalisé afin qu'il fonctionne correctement sans aucune modification.
Puis-je vous demander ce que vous n'aimez pas dans la bibliothèque standard (enfin, à part l'inconvénient évident - "paresseux à apprendre") ?
Ce n'est pas un inconvénient, je connais très bien SB, et cette connaissance me permet de comprendre à quel point tout est lourd et inefficace.
Au lieu d'envoyer une commande, vous lancez un grand-père pour un grand-père et un grand-père pour un navet.
Mais le principal inconvénient (selon Trade) est qu'il n'y a absolument aucun contrôle de l'exécution. Ils envoient juste une commande au serveur et laissent l'herbe pousser. Mais ils ont emballé Send de 10 façons, comme pour toutes les occasions, mais les cas se sont avérés être 100.
En ce qui concerne l'idéologie : l'héritage pour plus de 2 générations est une erreur, au-delà la compréhension et la flexibilité sont perdues.
La plupart des classes (vous avez raison) n'ont pas été inventées, elles ont juste été réinventées à partir de MFC, mais ce n'est pas un inconvénient, pourquoi réinventer la roue.
Mais je pense que le principal inconvénient est qu'ils ne peuvent pas s'y fier).
J'ai écrit à la fois avec et sans SB. Sans elle, vous êtes plus rapide et plus transparent. Il est trop polyvalent, il est donc lent dans les virages.
Dans Delphi, par exemple, il existe le concept de projet, qui implique une compilation conjointe. Et la division des programmes en 3 types est un peu douteuse en général, parce que le compilateur, en théorie, peut déterminer lui-même ce que fait le programme, mais puisqu'il va si loin que les indicateurs ne commercent que par la force, et pour l'EA vous devez mettre en œuvre le code à l'intérieur, alors nous ne pouvons qu'espérer que le cœur des développeurs fondra un jour et qu'ils permettront de faire des projets).
secondé,
Je pense qu'il serait utile d'ajouter un onglet FICHIERS pour que le marché puisse stocker des ensembles, des instructions, etc,
bien que l'onglet Discussion le permette, mais ce n'est toujours pas la même chose.
Voir MetaTrader 5 Client Terminal build 730 du 24 novembre 2012.
Super, comment j'ai pu manquer ça, aaah c'est les constructions d'avant les vacances.
Le croisement dans votre message signifie-t-il qu'ils le peuvent déjà ?
C'est justement l'inconvénient, je connais très bien SB, et cette connaissance me permet de comprendre à quel point tout est lourd et inefficace.
Merci pour votre réponse complète. Je n'ai pas d'objection catégorique à l'une de vos déclarations. Juste... quelques commentaires...
Au lieu d'envoyer un ordre, grand-père pour grand-père, grand-père pour navet.
Mais c'est ce qui donne au système sa flexibilité, et c'est ce qui nous permet d'envoyer à l'EA un historique personnalisé et une émulation de serveur. Si les commandes étaient envoyées directement par OrderSend() - nous devrions écrire ceci "Grand-mère pour grand-père, grand-père pour grand-père"... Ce n'est pas clair ce qui est mieux...
Mais le principal inconvénient (selon le commerce) est qu'il n'y a absolument aucun contrôle de l'application de la loi. Si vous "bump" une commande à un serveur et que vous ne vous en souciez pas. Mais ils ont emballé Send de 10 façons, comme pour toutes les occasions, mais les cas se sont avérés être 100.
Je n'ai pas assez d'expérience ici - je ne peux que théoriser. J'analyse moi-même les codes de retour, mais j'ai très peu d'expérience. Je suis d'accord pour dire qu'il n'y a pas assez de contrôle de l'exécution dans le SB lui-même.
Quant à l'idéologie : je considère que l'héritage pour plus de 2 générations est une erreur, de plus vous perdez à la fois la compréhension et la flexibilité.
Oui, en effet, un héritage trop profond est très préjudiciable à la compréhension. Mais en ce qui concerne la flexibilité, j'ai du mal à être d'accord. J'ai un tas de cas d'héritage de 4-5 générations, et cela ne semble pas poser de problèmes. Mais, je peux convenir que c'est le cas pour moi, pour d'autres cette profondeur d'héritage peut être un obstacle majeur.
Mais le principal inconvénient je pense qu'il n'est pas possible de s'y fier, vous écrivez quelque chose dessus et il sera retravaillé :)
Oui, je suis tout à fait d'accord avec cela.
J'ai écrit à la fois avec et sans SB. J'ai écrit avec le SB mais sans lui, je suis devenu plus rapide et plus transparent. Il est trop polyvalent, donc il est maladroit dans les virages.
J'ai apprécié SB pour sa capacité à créer un modèle de CT et à n'y connecter ensuite que des classes d'objets décrivant les entrées, la maintenance et les sorties. Je crains que sans SB, une telle idéologie ne conduise à la création de la même chose, seulement Own SB.
À propos de "plus rapide et plus transparent" - il me semble qu'une telle idéologie est bonne lorsque nous avons un TS traité dans son ensemble. Cependant, il me semble qu'il s'agit d'une grave erreur d'algotrading. TS ne doit être considéré que comme un ensemble de "cubes" - un ensemble de générateurs d'entrée, déterminant de l'entrée TP-SL, déterminant de l'entrée lot, contrôleur suiveur et ainsi de suite... Cette idéologie permet d'obtenir très rapidement des centaines de variantes différentes de TS, là où nous n'en avons que quelques unes "plus rapides et plus transparentes".
Par exemple, après avoir écrit cinq TS différents sans modèle - pour écrire le sixième, nous devrons tout recommencer, même en utilisant des parties de ces cinq systèmes. Après avoir écrit le modèle - nous y introduirons ces cinq systèmes uniquement en partie, et nous aurons ainsi jusqu'à cinq générateurs d'entrée, filtres d'entrée, déterminants TP-SL, etc. En les combinant, on obtient facilement une centaine de TS, parmi lesquelles on peut choisir les plus stables et les plus rentables.
Par conséquent, à mon avis, la lenteur de SB est vraiment une "arme à double tranchant", et son application ou sa non-application devrait être décidée dans chaque cas individuellement.
Super, comment j'ai pu manquer ça, ahhhhh ce sont les constructions de pré-nouvelle année.
Le fait de barrer la case dans votre message signifie-t-il qu'ils le peuvent déjà ?
Super, comment j'ai pu manquer ça, ahhh c'est les constructions d'avant le nouvel an.
Ce sujet a été abordé ici : https://www.mql5.com/ru/forum/3409#comment_408123