Projet du conseiller - page 7
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
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 ??? Je suis un imbécile qui utilise la "percée de la volatilité" en utilisant uniquement cet indicateur... ?
Je pense que vous avez votre propre compréhension 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.
Essentiellement
indicateur = un outil (instrument) qui montre tout changement dans quelque chose.
En ce sens, l'ATP est un indicateur.
Lorsque vous regardez le graphique, vous remarquerez que l'indicateur est le plus précis (c'est-à-dire que l'indicateur n'est pas un indicateur autonome - c'est un indicateur de position) et vous devez le garder sur le marché.
mon respect.
Я не вижу особой разницы - как я понимаю, WS (WareStore, вероятно ?) - это все тот же мой дата-провайдер.
Il s'agit d'une abréviation de WorkSymbol. L'abréviation courte est choisie à dessein, en raison de la référence fréquente à cet objet.
Je pense qu'il doit y avoir des étapes préliminaires dans l'initialisation de l'objet WS.
WS est une instance de l'objet CSymbol dont le constructeur par défaut utilise le symbole Symbol() courant. Par conséquent, WS ne nécessite pas d'initialisation de l'extérieur. Elle est simplement créée avec la classe de stratégie.
Il peut y avoir de nombreux conteneurs différents de différents symboles et de différentes échéances dans un EA. 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.
Le résultat est un noyau de méga-classe, auquel les classes d'experts ont accès. En quoi diffère-t-il du MQL de base, alors qu'il existe un noyau MetaTrader et des centaines de ses fonctions qui y accèdent ?
Si nous considérons MT4-5 lui-même comme le fournisseur de données, et que notre classe n'est utilisée que pour fournir un accès - alors il me semble déraisonnable que selon votre référence au prix Open, nous devions appeler la fonction CopyOpen() pour une valeur.
Exactement. Seul un tel appel garantit l'unité de la représentation des données et la synchronisation complète des états. Pas besoin de faire des mises à jour de devis (qui peuvent être oubliés), pas besoin d'utiliser un tas d'interrupteurs à bascule supplémentaires, qui surgissent inévitablement lors de la création d'un intermédiaire de stockage de données. Il n'est pas nécessaire de rechercher dans la base de données les données correspondant aux données demandées. Si mon EA le fait :
Il est alors garanti de savoir que WS.High[1] retournera à son extremum précédent, quelle que soit la façon dont l'environnement de négociation est mis à jour. Oui, il est trop coûteux d'appeler CopyHigh à chaque appel et de copier une seule valeur de double, mais c'est 100% fiable. Puisque les classes de couverture ne stockent pas de données, mais transmettent uniquement l'appel aux fonctions du système, nous ne pouvons pas avoir une situation où les données stockées ne correspondent pas à l'environnement actuel.
Je pense également qu'il est très déraisonnable de donner un accès global à toutes les variables à n'importe quel endroit du programme ; au contraire, j'essaie de n'avoir accès qu'aux structures et aux données qui sont nécessaires pour une action donnée à chaque endroit du programme. Tout le reste doit être inaccessible. L'idéologie du fournisseur de données permet juste de contrôler cet accès.
Georg, en fait, vous avez déjà créé cet accès global. Vous avez un grand fournisseur de superclasses auquel tout le monde accède. Il s'agit d'un grand pool global d'objets (indicateurs, séries chronologiques, etc.), qui est rassemblé sous l'enveloppe de la POO. En d'autres termes, dans l'exemple du fournisseur de données, la POO est devenue une fiction. Elle existe formellement, mais elle n'existe pas dans la réalité.
Georg, en fait, vous avez déjà créé cet accès global. Vous avez un seul grand fournisseur de super classe, auquel tout le monde a accès. Il s'agit d'un grand pool global d'objets (indicateurs, séries chronologiques, etc.) qui est assemblé sous l'enveloppe de la POO. En d'autres termes, dans l'exemple du fournisseur de données, la POO est devenue une fiction. Il est là formellement, mais il n'est pas là dans la réalité.
Non, je comparais les vitesses d'exécution lorsque je place un tampon dans le fournisseur de données ou que je reçois des données à chaque fois via CopyXXX - j'ai un accès beaucoup plus rapide à mon tampon. C'est pourquoi j'ai opté pour mes tampons, et le fournisseur de données est juste un stockage centralisé pour ces tampons.
En effet, la présence d'une "couche" - ce même fournisseur de données - entraîne un risque de désynchronisation des données. Mais jusqu'à présent, je n'ai jamais rencontré un tel problème, mais le fournisseur de données économise la vitesse de manière assez claire. En fait, je pense que ce test a déjà été réalisé par de nombreuses personnes - il s'est avéré que lors du traitement d'un tick, il est plus rentable de copier les données une fois et de les utiliser, plutôt que de se rendre à chaque fois au terminal pour chercher les données.
Maintenant, c'est différent ? Et la vitesse d'un certain nombre d'appels via CopyXXX pour chaque valeur double est la même que la vitesse d'un appel en une seule fois pour toute la plage, et ensuite - appel au tampon pour les valeurs ?
Non, je comparais les vitesses lorsque je place le tampon dans le fournisseur de données, ou que je récupère les données à chaque fois par CopyXXX - j'ai un accès beaucoup plus rapide à mon tampon. C'est pourquoi j'ai opté pour mes tampons, et le fournisseur de données n'est qu'un stockage centralisé pour ces tampons.
En effet, la présence d'une "couche" - ce même fournisseur de données - entraîne un risque de désynchronisation des données. Mais jusqu'à présent, je n'ai jamais rencontré un tel problème, mais le fournisseur de données économise la vitesse de manière assez claire. En fait, je pense que beaucoup ont déjà effectué ce test - tout le monde a reçu que lors du traitement des tick, il est plus rentable de copier les données une fois et de les utiliser, au lieu d'aller chercher les données à chaque fois dans le terminal.
Maintenant, c'est différent ? Et la vitesse du nombre d'appels via CopyXXX pour chaque valeur double est la même que la vitesse d'un appel en une fois pour toute la plage, et ensuite - appel au tampon pour les valeurs ?
Il ne fait aucun doute qu'il est beaucoup plus rapide de copier toutes les cotations en une fois dans la mémoire interne de l'EA (fournisseur de dates) et d'appeler ensuite les valeurs à partir de celle-ci, que d'appeler constamment le CopyBuffer. Mais c'est le prix à payer pour un système basé sur l'État. Fondamentalement, tout notre domaine - écrire des EA, des scripts, etc. - est la programmation de systèmes basés sur des états : nous avons un ordre - traiter les règles de son traitement. Il n'y a pas d'ordre - nous traitons les conditions de son ouverture.
Pour ce qui est de CopyBuffer, copier de grands morceaux de citations et mesurer le gain de performance n'est possible que dans des tests synthétiques. En pratique, dans 90% des cas, le Conseiller Expert travaille avec la dernière barre de chaque tick ou au moment de l'ouverture d'une nouvelle barre. Par conséquent, les données de la dernière barre sont toujours demandées, et il y a un appel constant de la fonction CopyBuffer qui copie la dernière barre dans le cache.
La seule véritable augmentation de la productivité est lorsque le conseiller expert demande les N dernières barres, où le nombre N est bien supérieur à 1. Mais quelle est la demande des N dernières mesures ? Il s'agit du travail dans la fenêtre glissante (99% de tout le travail du Conseiller Expert). Et la fenêtre coulissante, est un tampon circulaire dans son essence. Par conséquent, lorsque vous demandez les N dernières barres, en réalité, vous ne devez mettre à jour ou ajouter qu'une seule dernière barre. C'est-à-dire que tous ces trucs avec la copie de blocs de données sont une très belle histoire, mais ils ne fonctionnent pas dans le domaine pour lequel ils ont été créés, alors que les tampons en anneau fonctionnent très bien.
Maintenant mon CSymbol fonctionne simplement en passant le bon index. Mais je peux l'améliorer pour qu'il mette en cache N dernières barres et que N soit choisi par CSymbol lui-même, en fonction de l'indice maximal demandé. Et alors, sans aucun changement externe, CSymbol sur certaines tâches, fonctionnera plusieurs fois plus vite que l'appel permanent de CopyBuffer. C'est la puissance de la POO. Après une certaine surcharge associée à l'utilisation de wrappers supplémentaires, un saut qualitatif se produit, lorsque vous pouvez réduire considérablement l'utilisation de la mémoire ou du temps CPU grâce aux algorithmes adaptatifs.
Bonjour.
J'écris d'énormes blocs de code qui occupent des centaines de lignes. Presque aucun commentaire. Sans OOP. Le code est en russe. Tout fonctionne très efficacement. Je n'ai aucun problème d'orientation dans le programme, bien qu'il y ait une centaine de fichiers connectés. Probablement parce que je m'y suis habitué et que je me suis souvenu de tout il y a longtemps. L'essentiel est de connaître et de comprendre votre programme, tout le reste est secondaire. Je pense.
L'écriture d'énormes blocs de code occupant des centaines de lignes. Presque aucun commentaire. Pas d'OOP. Code en russe. Tout fonctionne très efficacement. Je n'ai aucun problème d'orientation dans le programme, bien qu'il y ait une centaine de fichiers connectés. Probablement parce que je m'y suis habitué et que je me suis souvenu de tout il y a longtemps. L'essentiel est de connaître et de comprendre votre programme, tout le reste est secondaire. Mon sentiment est que l'essentiel est de connaître son programme, et que le reste est secondaire.
Êtes-vous passé de 1C à MQL ?
Je suis autodidacte. Le premier langage de programmation que j'ai appris était MQL4. Après cela, j'ai pratiqué un peu en C# et C++.
Jamais entendu parler de 1C. Qu'est-ce que c'est ?
Quant à CopyBuffer, copier de grands morceaux de citations et mesurer le gain de performance n'est possible que dans des tests synthétiques. En pratique, dans 90% des cas, le Conseiller Expert travaille avec la dernière barre de chaque tick, ou au moment de l'ouverture d'une nouvelle barre. Par conséquent, les données de la dernière barre sont toujours demandées et il y a un appel constant du CopyBuffer, qui copie la dernière barre dans le cache.
Nous avons donc besoin de la vitesse dans le "test synthétique" - la vitesse devient critique lors de la recherche de variantes dans le testeur de stratégie. Le testeur de stratégie est pour moi un "goulot d'étranglement" là où nous avons besoin de rapidité.
Dans le travail réel, la rapidité de l'accès direct aux données via CopyXXX à chaque fois est suffisante. Mais, pour le prog dans le testeur - la différence de vitesse est très importante.
Mais c'est dans le "test synthétique" que nous avons besoin de rapidité - la rapidité devient critique lorsque l'on essaie des options dans le testeur de stratégie. Le testeur de stratégie est pour moi un "goulot d'étranglement" lorsque la vitesse est requise.
Dans le travail réel, la rapidité de l'accès direct aux données via CopyXXX à chaque fois est suffisante. Mais, pour le programme du testeur, la différence de vitesse est très importante.
Pour expliquer en termes plus simples : à la base de votre fournisseur de données se trouve la fonction CopyXXX, qui copie le dernier caractère. A la base de mon CSymbol se trouve également CopyXXX, qui copie le même dernier caractère. Les deux fonctions sont lentes. Par conséquent, votre code et le mien sont tous deux lents, puisque l'appel CopyXXX ne peut être contourné. Mais mon code est plus simple et plus petit. Alors pourquoi toute cette construction d'étages au-dessus de CopyXXXXX, si cela ne résout pas le problème de CopyXXX lui-même ?