Projet du conseiller - page 6
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
Dans le monde civilisé, les listes sont mises en œuvre par...
Pourquoi n'écrivez-vous pas une bibliothèque civilisée en MQL, et ensuite nous parlerons. Nous entendons ces cris depuis des années, et quand on y réfléchit, on commence carrément à faire du boudin.
MQ a vraiment fait une erreur avec les références dans CObject. Ils ne devraient pas être là. Et ces références sont utilisées dans des conteneurs très spécifiques comme CList. Mais là où il n'y a pas d'erreurs ? Des langues civilisées, vous dites ? Lisez la critique de Richter sur ce qu'il pense d'Object C# et des méthodes qu'il ne devrait pas contenir. Donc, parce que Richter a raison, nous devrions refuser d'utiliser C# ? C'est absurde. Alors arrêtez de vous empiler ici et allez enfin dans votre jungle procédurale.
Eh bien, oui, vous ne pouvez pas mettre des objets constants dans une liste.
Cependant, j'utilise constamment la fonctionnalité CObject, et aucune des critiques n'a offert quoi que ce soit de similaire aux objets tableaux et listes de la bibliothèque standard.
"La façon dont les choses devraient être faites", c'est ce que tout le monde crie. Mais pour suggérer quelque chose, tout d'un coup, il n'y a rien.
Même les participants qui proposent effectivement différentes solutions logicielles - qui ne remplacent pas le CObject - ne l'utilisent pas du tout ou utilisent moins souvent ses fonctionnalités, sans prêter attention à la "mise en œuvre par un seul endroit". Et cela signifie que la mise en œuvre est plutôt bonne.
Si elle était mauvaise, un remplacement aurait été suggéré depuis longtemps.
En général, le CObject natif est utilisé lorsque tout le reste est également basé sur la bibliothèque standard. En particulier, ceux qui partagent activement leurs sources ont tendance à unifier, à réduire le code écrit par eux-mêmes et le nombre de leurs propres bibliothèques pour faciliter la vie des utilisateurs externes. Mais chacun décide pour lui-même, s'il codifie pour lui-même ou pour la commodité des autres.
Cependant, je suppose que de nombreuses personnes utilisent leurs propres solutions (comme moi), elles ne voient simplement pas la nécessité de les proposer aux autres. Mais en général, je pense que ce serait mieux s'il y avait une norme basée sur des bibliothèques bien connues, comme MFC. C'est pourquoi je ne comprends pas vraiment MQ, pourquoi ils ont dû réinventer leur propre roue (ce qui est très controversé d'ailleurs) au lieu de porter une solution toute faite. Cependant, on peut dire la même chose du langage MQL lui-même ;)))
Mais en principe, je ne suis pas obligé de refuser CObject, j'ai juste fait ma remarque critique en réponse à la phrase, que quelqu'un devrait utiliser CMyCobject quand il y a un CObject très cool de MQ :)
Ecrivez une bibliothèque civilisée en MQL, et ensuite nous parlerons. Tu cries depuis des années, mais quand tu t'y mets, tu te mets à bodoyer carrément.
Eh bien, j'ai mes propres bibliothèques. Alors, de quoi voulais-tu parler ?
Je me suis vraiment planté avec les références dans CObject MQ. Ils ne doivent pas être là. Et ces références sont utilisées dans des conteneurs très spécifiques comme CList. Mais là où il n'y a pas d'erreurs ? Des langues civilisées, vous dites ? Lisez la critique de Richter sur ce qu'il pense d'Object C# et des méthodes qu'il ne devrait pas contenir. Donc, parce que Richter a raison, nous devrions refuser d'utiliser C# ? C'est absurde. Alors arrêtez de vous empiler ici et allez enfin dans votre jungle procédurale.
Ne soyez pas arrogant et grossier, je ne m'adresse pas à vous personnellement.
Pour ce qui est de "s'être trompé dans les liens", oui, c'est drôle, après avoir déjà tout peint à ce sujet. Bien que tout à l'heure vous ayez littéralement dribblé sur CObject, que c'est tellement génial, et que même les pointeurs n'y sont pas initialisés par défaut (au moins vous auriez dû étudier le code source de votre langage d'abord). Quoi qu'il en soit, je ne vois plus l'intérêt de vous dénigrer ici.
Mais je suis d'accord, il n'est pas toujours nécessaire d'utiliser la POO.
Disons que j'ai la classe CDataProvider:pulic CDataProviderI - fournisseur de données, qui fournit à Expert Advisor des séries chronologiques, des indicateurs, des données terminales et d'environnement. Dans un conseiller expert, il peut y avoir de nombreux TS - chacun d'entre eux recevrait des pointeurs vers des séries temporelles et des indicateurs du fournisseur de données (chaque TS n'aurait pas besoin de créer des séries temporelles - le fournisseur de données fournirait des pointeurs vers les séries temporelles nécessaires si elles existent déjà, et ne créerait que les séries temporelles qui n'ont pas encore été créées).
Lorsque vous devez obtenir un indicateur auprès du fournisseur de données, remplissez la structure de description de l'indicateur, puis demandez au fournisseur un indicateur qui pointe vers cette structure.
Par conséquent, chaque indicateur à l'intérieur du fournisseur de données doit être capable d'identifier sa structure (le fournisseur de données ne "connaît" que la classe de base abstraite de la structure) et, en fonction de celle-ci, de créer l'objet indicateur prêt, qui sera créé par le fournisseur de données.
Mais il serait déraisonnable de lancer un tel projet dans le seul but de vérifier une nouvelle idée d'indicateur. Par conséquent, pour ces nouveaux indicateurs, tout est "à la main", sans aucune POO. Cependant, si je vois qu'un indicateur est utile pour les conseillers experts, il est écrit "correctement", avec un support OOP complet et une création dans un fournisseur de données.
Lorsque j'ai testé tous les indicateurs de MT4 il y a environ 15 ans pour savoir s'ils étaient adaptés au trading en mode ordre inverse, je n'en ai trouvé qu'un seul qui permette de réaliser des profits sur une base quotidienne. La plupart des indicateurs sont basés sur des indicateurs intégrés, c'est pourquoi les résultats de trading sont faibles pour la quasi-totalité d'entre eux. Je pense que la première tâche de tout trader est d'étudier le marché pour déterminer la précision des prédictions ou la rentabilité d'un modèle.
avec respect.
L'essentiel est qu'ils ne puissent pas vous confondre avec la direction dans laquelle vous allez et voir la réalisation de leurs idées. Le but de tout ce cirque, de confondre et de diriger dans la mauvaise direction, loin du profit.
Vous avez vous-même répondu à la question de savoir pourquoi vous devriez utiliser CObject, plutôt qu'un vélo auto-écrit. Cela est nécessaire pour faciliter la vie non seulement des autres mais surtout de vous-même, car les mots "unification", "réduire le code écrit par vous-même", "réduire le nombre de vos propres bibliothèques" - c'est ce que tout développeur devrait s'efforcer de faire. C'est le Saint Graal du programmeur.
Bien sûr, la bibliothèque standard est obsolète. Le langage permet maintenant de faire des génériques, et les interfaces arrivent. Mais l'ancienne bibliothèque fonctionne et c'est une bonne unification, et comme on dit le mieux est l'ennemi du bien. Puisqu'il n'existe pas de solution parfaite ou optimale, il faut utiliser le bon.
Pour ce qui est de "l'erreur dans les liens", c'est drôle, alors que j'ai déjà tout écrit à ce sujet. Bien que plus tôt, vous ayez littéralement "chié" sur CObject en affirmant qu'il est si génial, et que même les pointeurs n'y sont pas initialisés par défaut (vous devriez au moins étudier le langage source pour commencer). De manière générale, je ne vois pas l'intérêt de vous dénigrer.
Personne ne rampera devant vous ici. Croyez-moi, les connaissances "cachées" que vous nous avez "révélées" ici sont connues depuis longtemps par beaucoup. Je ne discuterai même pas de l'initialisation des liens. Vous savez que vous avez formellement raison, alors vous essayez de me mettre le nez dans la même chose : lisez les maths, apprenez ce qui est NUL, etc. Mais tu n'as pas à m'apprendre. Vous êtes cool. Vous avez tout. Alors pourquoi vous nous lancez des perles ? Allez à votre bibliothèque. Regarde si ça devient 0,5% plus rapide.
Les indicateurs fractales et pinbars sont également souvent utilisés. c'est une solution merveilleuse pour de nombreux systèmes de trading qui utilisent les mêmes indicateurs dans leur trading. mais ils ne sont pas adaptés aux tests, c'est pourquoi ils le font par nécessité.
Il y a 15 ans, je testais tous les indicateurs de MT4 pour savoir s'ils étaient adaptés au trading en mode position inverse et je n'en ai trouvé qu'un seul qui s'est avéré rentable sur une base quotidienne.
Non, il faut juste que l'essence de l'indicateur soit bonne. Un indicateur n'est pas un Graal tout fait, mais simplement une expression commode de certaines particularités des mouvements de prix. Par conséquent, nous ne devons pas les traiter comme "la source finale du signal", mais simplement comme une "caractéristique du signal" et les utiliser comme un complexe. Et dans ce cas, de nombreux indicateurs commencent à être nécessaires dans la plupart des tests. En particulier, l'ATR, par exemple, je pense déjà à le standardiser dans le modèle d'un conseiller expert parce que je l'utilise pratiquement partout. Les MA sont aussi très souvent des indicateurs obligatoires. Fractales, indicateurs pinbar...
...
Mais, je suis d'accord, il est loin d'être toujours nécessaire d'utiliser la POO.
Disons que j'ai une classe CDataProvider:pulic CDataProviderI - un fournisseur de données, qui fournit à l'expert des séries chronologiques, des indicateurs, des données de terminal et d'environnement. Dans un conseiller expert, il peut y avoir de nombreux TS - chacun d'entre eux recevrait des pointeurs vers des séries temporelles et des indicateurs du fournisseur de données (chaque TS n'aurait pas besoin de créer des séries temporelles - le fournisseur de données fournirait des pointeurs vers les séries temporelles nécessaires si elles existent déjà, et ne créerait que les séries temporelles qui n'ont pas encore été créées).
Lorsque vous devez obtenir un indicateur auprès du fournisseur de données, remplissez la structure de description de l'indicateur, puis demandez au fournisseur un indicateur qui pointe vers cette structure.
Par conséquent, chaque indicateur à l'intérieur du fournisseur de données doit être capable d'identifier sa structure (le fournisseur de données ne "connaît" que la classe de base abstraite de la structure) et, en fonction de celle-ci, de créer l'objet indicateur prêt, qui sera créé par le fournisseur de données.
Mais il ne serait pas raisonnable de lancer ce projet dans le seul but de vérifier une nouvelle idée d'indicateur. Par conséquent, pour ces nouveaux indicateurs, tout est "à la main", sans aucune POO. Cependant, si je vois qu'un indicateur est utile pour les conseillers experts, il est écrit "correctement" - avec un support OOP complet et une création dans un fournisseur de données.
P.S.
A propos, dans le cas des indicateurs et du fournisseur de données, nous voyons l'avantage de l'héritage de virtualisation. Nous avons l'interface de base des paramètres de l'indicateur CIndicatorParametersI ; le descendant de cette interface est les paramètres réels de l'indicateur nécessaire. Lors de la demande de l'indicateur, nous déclarons ces paramètres et transmettons au fournisseur de données un pointeur vers l'interface abstraite. Ainsi, le fournisseur de données lui-même ne sait même pas quel indicateur est demandé - il est défini dans une fonction, dans laquelle l'indicateur est créé en fonction du nouveau type. Et quels sont exactement les paramètres passés - seul cet indicateur créé le sait, il extrait les paramètres requis de l'objet passé.
L'astuce est que presque partout à l'intérieur du fournisseur de données, il y a une simple classe de base de paramètres (ou indicateurs) - seules les fonctions les plus simples et les plus courantes des interfaces de base sont disponibles pour le fournisseur de données. Cela simplifie la modification du code (lorsqu'elle est nécessaire), et ne crée pas la tentation de "trafiquer" le code des indicateurs du fournisseur de données. Si vous voulez changer un indicateur, cela se fait uniquement à l'intérieur de l'indicateur, le fournisseur de données n'est qu'un stockage d'indicateurs, le maximum qu'il puisse faire est de créer un nouvel indicateur.
Je pense que vous rendez les choses trop compliquées. Le fournisseur de date est MetaTrader lui-même. C'est-à-dire que le fournisseur de date n'est pas vraiment nécessaire, il a seulement besoin d'une interface pratique pour travailler avec les données. Par exemple, dans mon Libera, il suffit d'écrire le prix d'ouverture de la dernière barre :
L'objet WS est toujours là, il est toujours à portée de main et fonctionne. La façon dont il le fait est cachée dans les coulisses. C'est tout l'accès aux données :)
s.o.p. La POO devrait réduire la complexité d'utilisation du système, et non l'augmenter. Si vous admettez que vous devez construire un jardin pour un simple contrôle, cela signifie que vous avez quelque chose qui ne va pas dans votre architecture avec le fournisseur. C'est-à-dire que vous avez programmé quelque chose que vous ne voulez pas toujours utiliser.Non, il faut juste que l'essence de l'indicateur soit bonne. Un indicateur n'est pas un Graal tout fait, mais simplement une expression commode de certaines particularités du mouvement des prix. Par conséquent, nous ne devons pas les traiter comme "la source finale du signal", mais simplement comme une "caractéristique du signal" et les utiliser comme un complexe. Et dans ce cas, de nombreux indicateurs commencent à être nécessaires dans la plupart des tests. En particulier, l'ATR, par exemple, je pense déjà à le standardiser dans le modèle d'un conseiller expert parce que je l'utilise pratiquement partout. Les MA sont aussi très souvent des indicateurs obligatoires. Fractales, indicateurs pinbar...
je voulais dire travailler en mode "toujours sur le marché" sur la base du signal de l'indicateur de retournement. encore une fois, je répète qu'il y a 15 ans, maintenant ma vision du marché a légèrement changé.
avec respect.
Je pense que tu rends les choses plus compliquées qu'elles ne doivent l'être. Le fournisseur de données est MetaTrader lui-même. En d'autres termes, vous n'avez pas vraiment besoin d'un fournisseur de dates, vous avez simplement besoin d'une interface conviviale pour travailler avec des données. Par exemple, dans mon Libera, il suffit d'écrire le prix d'ouverture de la dernière barre :
L'objet WS est toujours là, il est toujours à portée de main et fonctionne. La façon dont il le fait est cachée dans les coulisses. C'est tout l'accès aux données :)
s.w. La POO devrait réduire la complexité de l'utilisation du système, et non l'augmenter. Et si vous admettez vous-même que vous avez besoin de construire un potager pour un simple contrôle, cela signifie que quelque chose ne va pas dans l'architecture de votre FAI. C'est-à-dire que vous avez programmé quelque chose que vous ne voulez pas toujours utiliser.Votre (disons "vous") entrée "WS.Open[0] ;" diffère très peu de mon entrée "m_tcMainContainer.Open(0)".
Je pense qu'il doit y avoir une action préliminaire dans l'initialisation de l'objet WS.
Dans mon cas, nous devons appeler la fonction bool _LoadMainTimeseriesToLocalContainer(uint uiNeedBuffer).
Dans chaque partie d'un Expert Advisor (dans le générateur d'entrées, dans les contrôleurs de suivi et de sortie, c'est-à-dire dans les objets qui peuvent effectuer des actions commerciales), j'ai l'objet "Timeseries Container" - en fait, c'est un pointeur vers OHLCSTVtVr timeseries avec des options de service supplémentaires.
Il peut y avoir de nombreux conteneurs de différents symboles et de différentes échéances dans un conseiller expert. L'idéologie du fournisseur de données permet de ne pas les dupliquer. Puisqu'en réalité, toutes les séries temporelles y sont stockées, et les conteneurs ne font que pointer vers ceux qui sont nécessaires.
Je ne vois pas de grande différence - si je comprends bien, WS (WareStore, probablement ?) est toujours le même fournisseur de données. C'est juste que mon dataprovider concentre également le reste des données - indicateurs, symboles (objets CSymbolInfo), terminal (objet CTerminalInfo), qui possède également une collection de graphiques. A chaque rafraîchissement, la série temporelle est mise à jour (si nécessaire) - ici l'idéologie est proche de celle de la bibliothèque standard.
Si nous considérons que MT4-5 lui-même est un fournisseur de données, et que notre classe est utilisée uniquement pour fournir un accès - alors il s'avère que selon votre référence au prix Open, nous devons appeler la fonction CopyOpen() pour une valeur - cela me semble déraisonnable.
Donner un accès global à toutes les variables à n'importe quel endroit du programme, je pense aussi que c'est extrêmement déraisonnable, au contraire, j'essaie d'avoir accès seulement aux structures et aux données qui sont nécessaires pour cette action à chaque endroit du programme. Tout le reste doit être inaccessible. L'idéologie du fournisseur de données me permet de contrôler cet accès.
je ne le considère pas comme un indicateur, il montre la volatilité moyenne du marché sur une certaine période de temps, il ne convient pas comme signal d'entrée (il peut être appliqué comme un filtre, rien de plus).
je voulais dire travailler en mode "toujours sur le marché" sur la base du signal de l'indicateur de retournement, et encore, il y a 15 ans, maintenant ma vision du marché a légèrement changé.
Respectueusement.
Que voulez-vous dire par "l'ATR ne compte pas comme un indicateur" ?
Et comment peut-on dire qu'il "ne convient pas comme signal d'entrée ??? Et je suis un idiot, j'utilise l'entrée "ventilation de la volatilité" en utilisant uniquement cet indicateur... ?
Je soupçonne que vous avez votre propre compréhension de l'essence des indicateurs... Pour moi, un indicateur est un objet qui peut produire une certaine valeur variable, en fonction du temps. En fait, même un graphique ordinaire en chandeliers des prix est également un indicateur. Mais pour vous, c'est autre chose... Par conséquent, notre compréhension est différente.