Règles de structure. Apprendre à structurer des programmes, explorer les possibilités, les erreurs, les solutions, etc. - 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
Ne croyez pas que je fais le malin, mais regardez à nouveau cette architecture d'écriture d'un CT de combat. Il n'y a pas de retour d'information.
Il existe des positions virtuelles et un environnement de négociation réel qui s'adapte à la virtualité.
Dans ce cas, il n'est même pas important que la compensation soit dans la plate-forme ou dans un autre système comptable.
Je pense que c'est une structure très intéressante, en particulier pour les stratégies à grande vitesse qui ne peuvent pas être vérifiées par le testeur habituel.
Seulement, ce n'est pas très clair pour le "synchroniseur intelligent". Ils veulent probablement parler d'un copieur adaptatif d'ordres commerciaux dont la tâche, si je comprends bien, est d'ajuster la rentabilité virtuelle / la rentabilité de la stratégie et l'état actuel du marché - liquidité, vitesse d'exécution, etc...
En général, il serait bon que ce testeur et ce synchroniseur ne soient pas intégrés de manière monolithique dans le conseiller expert, mais qu'ils constituent un module externe distinct.
Dans ce cas, n'importe quel conseiller expert ou plusieurs peuvent y être connectés et même utiliser sélectivement les signaux les plus appropriés.
Je me demande si cela est réaliste en utilisant uniquement MQL...
Il s'agit d'un module distinct en termes de logique.
Par exemple, le service Signaux est un module séparé, qui n'est en aucun cas lié au TS :
Il traduit simplement les positions sources virtuelles (elles sont virtuelles pour vous) dans votre environnement de négociation.
Curieusement (pas de manière optimale), bien sûr, mais cela se traduit.
Il s'agit d'un module distinct en termes de logique.
Par exemple, le service Signaux est un module distinct, qui n'est en aucun cas lié au TS :
Il traduit simplement les positions sources virtuelles (elles sont virtuelles pour vous) dans votre environnement de négociation.
Curieusement (pas de manière optimale), bien sûr, mais cela se traduit.
Il s'avère qu'il existe un traducteur Google qui traduit de travers mais fera l'affaire si vous n'avez pas besoin de le comprendre, mais si vous avez besoin de le comprendre précisément - apprenez la langue).
Je serais satisfait d'une option intermédiaire - un traducteur personnel de haute qualité (module), lorsque la traduction est bonne et qu'il n'est pas nécessaire d'écrire du code dans chaque EA.
Comprendre comment structurer un programme s'acquiert avec l'expérience. Chacun ici a des expériences différentes, et donc l'ordre et les règles de structuration seront uniques. En outre, ces règles évolueront au fil du temps, c'est-à-dire que ce qui semblait être une structure idéale il y a quelques années pourrait aujourd'hui ne pas résister à la critique la plus légère.
La structure des programmes en MQL est un morceau à part, car il s'agit par essence d'un DSL, contrôlé par des événements provenant du terminal (bien que d'énormes progrès aient été réalisés pour le rapprocher des langages à usage général). Je pense que pour la description des stratégies de trading, le meilleur moyen est une machine à états, et il y a déjà eu quelques articles à ce sujet ici. En fait, la structure dégénère en un grand cas avec beaucoup d'enclaves pour la réalisation de chaque cas.
En faisant abstraction des tâches commerciales, j'attribue généralement une partie centrale, qui ne sait rien des spécificités de l'interaction avec l'utilisateur. Son but est de fournir un moyen de se remplir de données, de résoudre le problème sur la base des données reçues et de produire le résultat. Le noyau peut se composer physiquement de plusieurs fichiers, mais tous doivent être connectés logiquement et ne fournir à l'extérieur que des méthodes pour recevoir des données et des méthodes pour renvoyer des données, et rien d'autre. L'analogie la plus simple est un hachoir à viande.
La deuxième chose qui me semble importante est de localiser les parties à modifier (ou les parties qui pourraient potentiellement être modifiées) et de les séparer dans une abstraction distincte. Grâce à cette approche, nous pouvons passer de manière transparente d'une implémentation à l'autre du mécanisme (par exemple, en changeant le mécanisme d'ouverture de position, nous pouvons virtualiser les échanges). Les différentes implémentations sont commodément stockées dans un dossier séparé avec un nom générique.
La structure du projet ressemblera à un arbre dont le tronc (Core) est constitué de différents sous-systèmes (Subsystems) et dont les branches de comportement modifiable (Behaviour) divergent. Et à côté de lui, il y aura des jumelles (Reporting, GUI) pour regarder cet arbre depuis l'angle nécessaire et une hache et une tronçonneuse (Actions, GUI) pour nous fournir l'interaction nécessaire avec cet arbre.
Des machines à états simples au service du développeur
Des machines à états simples au service du développeur
Donnez au moins un exemple approximatif à appliquer à nos réalités.
Vous êtes vraiment quelque chose :) La mise en œuvre de toute stratégie est essentiellement une machine à état.
Je comprends. J'ai demandé un exemple d'une telle machine à la lumière de l'article sur le charabia.
Oh, ok. Il y a eu un article où le mec a fait un "analogue" d'une machine à état. Et il poussait cette technologie comme une innovation de programmation de pointe).
Mais je ne me souviens pas d'un article substantiel sur les machines à états ici. Je ne m'en souviens pas ici.
Donnez au moins un exemple approximatif appliqué à nos réalités.
Ahaha, ça me rappelle "quelle sera votre preuve".
J'ai juste cherché sur Google "state machine", choisi le contenu que je préférais et l'ai téléchargé ici.
Je ne prouve rien, je ne réfute rien. Article intéressant.
En général, je suis contre les dogmes. Si une personne l'utilise, cela ne veut pas dire qu'elle conviendra à une autre.
Mais en lisant le code de quelqu'un d'autre, je rencontre souvent des analogies avec les machines à états. C'est juste une observation.