Règles de structure. Apprendre à structurer des programmes, explorer les possibilités, les erreurs, les solutions, etc. - page 18
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
Oh, Vladimir, ce n'est pas si facile avec ton circuit. Vous dites qu'il suffit de réécrire le pilote ? Eh bien, j'ai compté beaucoup plus de pièces dépendant de la plate-forme :
Comment obtiendrez-vous l'historique du marché et l'historique des transactions ? Et l'information sur la position actuelle ne sera pas prise dans le terminal, par hasard ? Et si vous devez implémenter le module de volatilité - une API de plus dépendant de la plateforme ?
Allez-vous écrire des adaptateurs ? Combien y en aura-t-il ? Pour l'historique du marché - un adaptateur, pour l'historique des transactions - un autre, pour le travail avec les positions - un troisième. Au final, il y a donc deux fois plus de modules, mais la même quantité de code dépendant de la plateforme.
Ce n'est pas comme ça que je vois le problème.
Tout ce qui est rouge est assez stable, tout ce qui vient de la plate-forme ne change pas au fil des ans, si vous avez besoin d'une autre plate-forme, il y a aussi une API bien établie, la réécriture ne pose aucun problème.
Mais tous les modules avec des flèches vertes sont propres, et presque toujours en cours de retravail (il n'y a pas de limite à l'idéal).
Le prévisionniste directionnel a été écrit, puis est venue la nouvelle idée d'approfondir et d'élargir, bien, comme maintenant c'est acheter, mais nous devons nous préparer à vendre, réduire lentement le volume.
J'ai donc commencé à utiliser deux modules.
MM Corrector est également un schéma dynamique, il fonctionne maintenant avec des positions, puis soudainement il a eu une idée et a décidé de le changer pour des positions longues (entrée en douceur sur le marché).
Market Driver devrait être stable parce qu'il a une sortie vers une API dépendante de la plateforme, donc la formalisation est claire, mais il sera vraiment désordonné parce que l'API offre beaucoup de possibilités.
Ce n'est pas comme ça que je vois le problème.
Tout ce qui est rouge est assez stable, tout ce qui vient de la plateforme ne change pas depuis des années, si vous en avez besoin pour une autre plateforme il y a aussi une API bien établie, la réécriture n'est pas un problème.
L'une des idées importantes de ce système n'est pas le nombre de pièces dépendant de la plate-forme, mais leur localisation stricte. C'est-à-dire : le TS lui-même (prédicteurs + modules MM) - il s'agit d'une conception indépendante de la plateforme, mais les sources de données sont les indicateurs et le moteur de marché, respectivement dépendants (l'historique des transactions, alimenté à l'entrée du correcteur de recommandations - est aussi essentiellement l'indicateur).
La conséquence - une zone d'intervention clairement délimitée et sans chevauchement à
1. La migration.
2. Amélioration du TS, en particulier de la mise à l'échelle.
Mais tous les modules avec des flèches vertes sont propres, et presque toujours une refonte active (il n'y a pas de limite à l'idéal).
Le prévisionniste directionnel a été écrit, puis est venu la nouvelle idée d'approfondir et d'élargir, bien, comme maintenant il est acheter, mais nous devons nous préparer à vendre, réduire lentement le volume.
J'ai donc commencé à utiliser deux modules.
Le correcteur MM est également un schéma dynamique, il fonctionne maintenant avec la position, puis tout d'un coup, il est devenu sage et a décidé de la changer pour l'équité (entrée en douceur sur le marché).
Le Market Driver devrait être stable parce qu'il a une sortie vers une API dépendante de la plateforme, donc la formalisation est claire, mais il y aura beaucoup de désordre parce que l'API fournit beaucoup de fonctionnalités.
Personne n'a promis l'absence de complications :) Mais imaginez que tous ces appels directs à l'API ne soient pas localisés dans le pilote, mais mélangés aux codes des prédicteurs et des modules MM..............
;)
Nikolay, votre post est très sensé, cependant je m'engage à défendre le schéma proposé (son universalité).
Je suis d'accord, je veux juste clarifier (en profitant de l'occasion) pour Vasily. Une des idées importantes dans le schéma n'est pas le nombre de parties dépendantes de la plateforme, mais leur localisation stricte. C'est-à-dire : le TS lui-même (prédicteurs + modules MM) - il s'agit d'une conception indépendante de la plateforme, mais les sources de données sont les indicateurs et le moteur de marché, respectivement dépendants (l'historique des transactions, alimenté à l'entrée du correcteur de recommandations - est aussi essentiellement l'indicateur).
La conséquence - une zone d'intervention clairement délimitée et sans chevauchement à
1. Migrations.
2. Amélioration du TS. En particulier, mise à l'échelle.
Cependant, si, à chaque modification, nous nous en tenons soigneusement à la division entre les parties du système qui dépendent de la plateforme et celles qui sont indépendantes, alors, par exemple, dans notre situation actuelle, nous pouvons facilement prendre en charge le développement d'EA pour les deux plateformes (MT4/5), ce qui serait un problème dans les systèmes de trading dépendant de la plateforme.Il peut y avoir n'importe quel nombre de modules à l'intérieur des composants marqués dans le schéma. C'est normal. Je pense que seule leur disposition claire en pipeline est utile. Ils ne doivent pas être mélangés à l'intérieur du code sans une nécessité absolument inévitable, c'est à dire Vous devriez éviter autant que possible de mélanger les modules. Cela vous permet d'avoir toujours des points d'ancrage bien définis et pratiques pour les modules lors de la mise à l'échelle vers les multitools. Regardez le schéma sous cet angle, vous le trouverez vous-même.
Voir ci-dessus. // Mais l'entrée du correcteur MM est le point le plus pratique pour intégrer un nuage de prévisionnistes mono-devise (mono-instrument plus précis) dans une cuisine multi-devise (multi-instrument).Personne n'a promis l'absence totale de complexité. :) Mais pensez que si tous ces appels directs à l'API ne sont pas localisés dans le pilote, mais mélangés avec les codes des prédicteurs et des modules MM..............
;)
OK, prenons cela comme base (mais ajoutons un module d'arrêt, car cela semble raisonnable et personne n'a d'objection),
et pensez à ce qui manque dans ce schéma, ou refaites-le.
OK, prenons-le comme base (ajoutons seulement un module pour travailler avec les arrêts, cela semble raisonnable et personne n'a d'objection),
et réfléchissez à ce qui manque encore dans ce circuit, ou retravaillez-le.
Je vais penser à retravailler-améliorer (laisser cuire).
Le manque est plus évident - ce schéma manque manifestement de l'interface graphique (sous-système de contrôle visuel). Je veux développer un schéma unifié (et pratique !) d'interaction du conseiller expert avec l'interface graphique. Jusqu'à présent, je suis spontané en la matière, ce qui m'ennuie vraiment. J'aimerais atteindre le même objectif (abstraction totale des données dans les deux sens). C'est pourquoi j'ai proposé la tâche de l'interface EA/GUI pour la formation, je m'y intéresse d'un point de vue mercantile, je voulais avoir des idées du public.
Il peut y avoir n'importe quel nombre de modules à l'intérieur des composants mis en évidence dans le schéma. C'est normal. Je trouve seulement utile de les organiser dans un pipeline clair. Qui ne devraient pas être mélangés dans le code sans une nécessité absolument inévitable. C'est-à-dire Cela vous permet d'avoir toujours des points d'ancrage bien définis et pratiques lorsque vous vous déplacez vers les multitools. Regardez le diagramme sous cet angle et vous le trouverez vous-même.
L'étalement illimité des modules entraîne de graves problèmes à l'avenir. La logique de l'Expert Advisor est pratiquement dispersée dans différents modules. Les modules eux-mêmes interagiront les uns avec les autres, et rien ne garantit que les liens entre eux ne deviendront pas un enchevêtrement. A mon avis, tous les carrés marqués en vert sont des éléments d'un système de trading. Leur décomposition en différents modules viole l'un des principaux principes de programmation : l'encapsulation des données et des méthodes dans une même tâche.
Puisque tout le monde a commencé à publier ses propres schémas, je vais continuer aussi. Cette fois, il s'agit d'un schéma encore plus abstrait :
Les flèches noires décrivent des relations rigides. Les gris sont des interrelations privées à l'intérieur du module, ils ne sont pas importants. La classe du robot de trading a également le droit de s'adresser directement à l'API de la plate-forme, mais cela réduit l'indépendance vis-à-vis de la plate-forme.
L'étalement illimité des modules entraîne de graves problèmes à l'avenir. La logique de l'Expert Advisor est pratiquement dispersée dans différents modules. Les modules eux-mêmes interagiront les uns avec les autres, et rien ne garantit que les liens entre eux ne deviendront pas un enchevêtrement. A mon avis, tous les carrés marqués en vert sont des éléments d'un système de trading. Leur décomposition en différents modules viole l'un des principaux principes de programmation : l'encapsulation des données et des méthodes dans une même tâche.
Puisque tout le monde a commencé à publier ses propres schémas, je vais continuer aussi. Cette fois, il s'agit d'un schéma encore plus abstrait :
Les flèches noires décrivent des relations rigides. Les gris sont des interrelations privées à l'intérieur du module, ils ne sont pas importants. De même, la classe du robot de trading a le droit d'accéder directement à l'API de la plateforme, mais cela réduit l'indépendance vis-à-vis de la plateforme.
Pour ce qui est de la refonte et de l'amélioration, je vais y réfléchir (laisser infuser).
Le manque est plus évident - ce schéma manque évidemment de GUI (sous-système de contrôle visuel). Je veux développer un schéma unifié (et pratique !) d'interaction entre le conseiller expert et le GUI. Jusqu'à présent, je suis spontané dans ce domaine, ce qui m'ennuie vraiment. J'aimerais atteindre le même objectif (abstraction totale des données dans les deux sens). C'est pourquoi j'ai proposé la tâche de l'interface EA/GUI pour la formation, je m'y intéresse d'un point de vue mercantile, je voulais avoir des idées du public.
Partir de la tâche. Quelles sont les tâches les plus demandées dans l'interface graphique ?
Partez de là. Décrivez ce que vous voulez obtenir, sélectionnez des rubriques communes, créez un cadre, puis ajoutez d'autres éléments et voyez à quel point il est facile de modifier le cadre.
Ensuite, vous comprendrez comment cela doit être, réécrivez le tout à nouveau. Je le vois comme ça.
MetaDriver le dit bien, et son système est correct. Dick_fx ajouterait également que le "pilote de trading" devrait travailler avec 10 à 20 plateformes pour utiliser les meilleurs prix.
Mais l'utilisation d'un système aussi correct ne convient que dans des conditions idéales - pas d'erreur de stratégie, pas d'intervention de l'utilisateur, pas de force majeure... Et en réalité, c'est rarement le cas.
Laissez-moi vous donner un exemple de dick_fx : 25 stratégies fonctionnent, l'agrégateur (Trade Driver) les rassemble en une position nette et les met sur le marché, tout est OK. Soudain, quelque chose ne va pas dans la 17ème stratégie et elle donne des prévisions malsaines - elle dit d'ouvrir à 50% du dépôt. Le conseiller expert s'ouvre docilement.
Que fait un casier trivial à la MT4 :
Passons maintenant à la "comptabilité correcte". Que doit faire le trader pour corriger l'erreur (une transaction avec une marge de 50 % - une erreur de logique évidente) ?
La question est : lequel est le plus facile ? Évidemment, la variante avec MT4.
Et qu'est-ce qui est le moins cher ? Évidemment, l'option Netting.
Quelle est la conclusion ? Réaliser un pilote de marché avec une interface graphique à partir de MT4 ;)
Et encore une chose.
C'est tout le raisonnement des "bons" traders, et même des programmeurs. S'ils le font pour leur propre plaisir, sur le compte avec un bon dépôt, alors c'est la seule façon de le faire.
Si nous abordons la question de l'écriture experte, il s'avère que personne n'a besoin de la "bonne" écriture. La foule des commerçants-clients ne peut pas être modifiée, il faut donc écrire "pour eux".
L'option "quitter mon travail" est acceptée ! =)
Et encore une chose.
C'est tout le raisonnement des "bons" traders, et même des programmeurs. S'ils le font pour leur propre plaisir, sur le compte avec un bon dépôt, alors c'est la seule façon de le faire.
Si nous abordons la question de l'écriture experte, il s'avère que personne n'a besoin de la "bonne" écriture. La foule des commerçants-clients ne peut pas être modifiée, il faut donc écrire "pour eux".
L'option "quitter mon travail" est acceptée ! =)