Organiser le cycle de commande - page 4
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
Elle ne le sera pas, car elle n'est pas forte.
Tout d'abord, le TS est écrit pour le testeur, où les conditions de trading sont idéales. Si tout va bien, ils essaient alors d'écrire la version live de manière à ce qu'elle soit aussi proche que possible de ce qu'ils voient chez le testeur. Toute autre approche de l'écriture de la TS relève du hasard, et non de l'algorithme de l'idée.
Voici donc la question fondamentale : quelle est la situation de combat la plus proche d'un testeur ? J'ai exprimé mon opinion (et donné un exemple), j'ai entendu la vôtre.
Je suis confronté à la tâche de transposer la logique de négociation d'un conseiller expert du test en tic-tac dans le testeur de stratégie (MT4) à son fonctionnement sur un compte réel.
Mon raisonnement :
Dans le testeur, le conseiller expert fonctionne non seulement dans des conditions de trading idéales, mais aussi dans un autre mode - en temps réel, c'est-à-dire qu'il a le temps de calculer le TS, d'envoyer un ordre et d'obtenir sa réponse en un seul tick, mais ce n'est pas le cas dans le trading réel. Il semble que nous ayons en quelque sorte deux robots différents - l'un en temps réel et l'autre en temps différé. Si nous envoyons/modifions un ordre (même un seul !) à un compte réel = ping + temps d'exécution, etc. = au mieux 100-500ms, et pendant ce temps les ticks passent et doivent être comptés - et nous restons, attendons... et ensuite nous entrons dans le flux au hasard (nous ne savons pas où le prix a évolué pendant ce temps par rapport à nos moyennes de tic-tac. + nous avons dû manquer certains des tics les plus rapides et généralement les plus importants). Par conséquent, il se peut qu'il ne reste rien de la stratégie que nous avons exécutée dans le testeur.
C'est pourquoi, après réflexion, je suis arrivé à la conclusion suivante :
Après réflexion, j'en suis arrivé à la conclusion suivante :
Oui, j'utilise la même approche - une sorte de testeur idéal interne avec ses propres ordres ouverts et un copieur qui essaie de matérialiser ces ordres virtuels. Ce système permet de contourner très facilement de nombreux problèmes graves.
Dans MT5, c'est plus facile car nous pouvons demander l'historique des tics. Et vous pouvez le demander pour plusieurs symboles.
Ce n'est pas une question de temps, c'est une question de logique (sur le temps, c'est un autre sujet ;-) ). Votre logique (et la mienne, puisque je suis d'accord avec tout, y compris l'analogie avec la voiture) est de faire l'analyse de l'environnement "en une seule fois et en un seul morceau", plutôt qu'au coup par coup. Le traitement des éventuels effets secondaires est reporté à la prochaine exécution, car ces effets seront intégrés dans le nouvel environnement commercial.
Eh bien, s'il n'y avait pas de correction du temps, alors les deux logiques (la mienne et celle de fxsaber) seraient identiques - tous les ordres seraient traités à chaque tick, même après plusieurs erreurs.
L'objectif est précisément de se rapprocher de la réalité avec une exécution non instantanée du modèle idéal obtenu lors des essais.
Oui, j'utilise la même approche - une sorte de testeur idéal interne avec ses ordres ouverts et un copieur qui essaie de matérialiser ces ordres virtuels.
Si vous concrétisez votre approche (en boucle, en restant sur la première commande jusqu'à ce qu'elle se synchronise avec la réalité), vous risquez de rencontrer le même problème de perte de vue des commandes restantes (ou simplement de leur traitement ultérieur). Mais il s'agit du même sujet, prétendument terminé).
Si vous concrétisez votre approche (en boucle, en restant sur la première commande jusqu'à ce qu'elle se synchronise avec la réalité), vous risquez de rencontrer le même problème de perte de vue des commandes restantes (ou simplement de leur traitement ultérieur). Mais il s'agit de la même question qui est censée avoir été résolue).
C'est comme ça qu'on fait du commerce !
Nous attendons un exemple OOP. Et je le vois toujours comme la même colonne vertébrale sous forme de boucle. La logique ne changera pas, car il faudra d'abord déterminer ce qui doit être changé, puis se prononcer sur les décisions que nous avons déjà prises.
Je n'écrirai pas d'exemple spécifiquement pour cette tâche. Mais vous pouvez voir un concept simplifié de l'approche dans mon blog. Là, la file d'attente n'est pas analysée en profondeur mais seulement vérifiée pour voir si elle est vide. Ceux qui le souhaitent peuvent l'améliorer.
Si l'on entend par logique la tâche "modifier une pile de commandes en raison de l'évolution des prix", il n'y a qu'une seule tâche. La question est de savoir ce qui est le plus important : modifier toutes les commandes ou les modifier pour les adapter aux derniers prix? En fonction de vos préférences, la logique sera différente. Une simple boucle permettrait de garantir que tous les ordres sont modifiés, et je suis favorable à cette option. Comme il a déjà été dit, la POO fournit une division claire de la tâche en blocs de responsabilité, et sur la base de cette décomposition, "toutes les commandes" est plus importante que "la pertinence du prix". Cela est évident même si les prix changent tout le temps et que les commandes ne sont là qu'occasionnellement. Ils sont plus importants.
L'OLP apporte de la clarté en divisant la tâche en blocs de responsabilité, et sur la base de cette décomposition, "toutes les commandes" sont plus importantes que "la pertinence du prix".
Sur la base de cette décomposition, il ne reste que la séparation. La "pertinence du prix" dans le cadre de cette OOP est obtenue en fixant une place dans la file d'attente.
C'est un peu une "philosophie" maintenant. Le traitement se fait par file d'attente d'ordres et non par flux de ticks comme le suggère l'alternative. Quoi qu'il en soit, je me retire de cette discussion. Tous les arguments ont déjà été présentés.
Quoi qu'il en soit, je me retire de cette discussion. Tous les arguments ont déjà été présentés.
Il y a déjà une tendance à finir de cette façon.
Nous allons aborder ci-dessous un sujet qui ne concerne pas seulement MT4, mais aussi MT5 avec d'autres plateformes. Mais la logique sera écrite en MQL4 pour une perception facile, donc dans cette branche.
Le plus souvent, l'épine dorsale (la chair de tout ordre) de la modification/suppression d'un ordre se résume à la logique suivante
Maintenant, l'approche est rare, mais beaucoup plus correcte.
Après l'envoi d'un ordre de transaction, l'environnement commercial change, il est donc conseillé d'exécuter l'ensemble de la logique commerciale du TS à partir de zéro immédiatement après la réponse du serveur commercial.
Le bouclage est l'une des astuces de programmation les plus dangereuses. Il provoque des erreurs étranges, qui se produisent rarement et qui sont presque impossibles à analyser.
Au lieu de boucler, vous devez au contraire essayer de terminer le fil utilisateur le plus rapidement possible. Si vous voulez garder la main sur le pouls - analysez OnTradeTransaction dans MT5. MT4 n'est généralement pas adapté à de telles boucles, car la simplicité est, comme on dit, pire que le vol.