Organiser le cycle de commande - page 3
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
Si vous devez sacrifier le contrôle de tous les ordres de la CT pour le faire, absolument.
Imaginez : vous avez une flotte de 4 camions. Chacun d'entre eux transporte des marchandises de valeur d'un point A à un point B. Vous devez surveiller l'itinéraire.
Que préférez-vous : avoir une communication toutes les minutes - avec l'un d'entre eux, ou toutes les 2 minutes - avec tous ?
Dans le second cas, le délai sera légèrement plus long, et les quatre devront peut-être faire un petit détour si vous ne parvenez pas à les acheminer à temps. Mais dans l'ensemble, ce sera mieux pour les affaires que de dépenser un camion et de perdre les trois autres.
Merci pour l'association, mais cela ne semble pas correspondre à une logique commerciale. La question semble être fondamentale et touche à des principes très différents de la construction des CT.
La seule façon d'éviter cette situation serait d'utiliser des commandes asynchrones.
Sinon, il y aurait toujours une boucle sur la liste des commandes à exécuter, qui est essentiellement une boucle sur les commandes.
Ce n'est que dans une situation de file d'attente qu'il faudrait encore prendre des dispositions pour remplacer un ancien ordre non exécuté relatif à un ordre par un ordre plus récent. Sinon, la file d'attente pourrait déborder et les commandes seraient envoyées hors de la file d'attente - obsolète.
Merci pour l'association, mais cela ne semble pas correspondre à une logique commerciale. La question semble être fondamentale et touche à des principes complètement différents de la construction des CT.
Je suis prêt à écouter votre association. Oui, la question est fondamentale.
Je ne suis pas d'accord. Une file d'attente avec exécution différée des commandes donne déjà de l'asynchronie. Nous n'envisageons pas un nouvel environnement dans la boucle de commande. En effet, il ne peut y avoir qu'une seule commande dans la file d'attente pour modifier une commande particulière.
La demande d'un nouvel environnement, en général, prend un minimum de temps. La majeure partie du temps est consacrée à l'attente d'une réponse du serveur.
Vous pouvez déléguer l'exécution d'une commande à un autre (ou même à plusieurs autres) EA, mais il s'agira toujours d'une exécution séquentielle de la commande. Je ne pense pas que le résultat sera différent du cycle de commande intégré.
Prêt à écouter votre association. Oui, la question est fondamentale.
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), la vôtre est entendue.
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 sorte que, dans le monde réel, elle soit aussi proche que possible de ce qu'ils voient dans 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 n'ai toujours pas entendu pourquoi, selon vous, en travaillant avec la première commande de la liste, les résultats seront plus proches du testeur (nous discutons toujours d'un système avec plusieurs commandes).
Je n'ai toujours pas entendu pourquoi vous pensez que les résultats seront plus proches du testeur lorsqu'on travaille avec le premier ordre de la liste (on discute toujours d'un système à plusieurs ordres).
Et ceci est presque postulé plutôt que prouvé, malheureusement. Comme vous le souhaitez.
Oui, il n'est pas nécessaire de déformer quelque peu mon approche, il ne s'agit pas de la première commande, il s'agit de redémarrer l'ensemble du TS après toute pause.
Et ceci est presque postulé plutôt que prouvé, malheureusement. Ni l'un ni l'autre n'est votre option.
Oui, il n'est pas nécessaire de déformer quelque peu mon approche, il ne s'agit pas de la première commande, il s'agit de redémarrer l'ensemble du TS après toute pause.
Je suis d'accord, travailler uniquement avec le premier ordre ne fonctionnera que dans certaines circonstances.
Je pense que la discussion s'est épuisée.
Je pense que la discussion s'est épuisée.
Oui, merci. La façon dont la discussion a été menée était très différente des discussions parallèles...
La demande d'un nouvel environnement prend généralement un minimum de temps. La majeure partie du temps est consacrée à l'attente d'une réponse du serveur.
Vous pouvez déléguer l'exécution d'une commande à un autre (ou même à plusieurs autres) EA, mais il s'agira toujours d'une exécution séquentielle de la commande. Je ne pense pas que le résultat sera différent de la boucle intégrée sur les commandes.
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 l'automobile) 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 effets secondaires éventuels est reporté à la prochaine exécution, car ces effets seront intégrés dans le nouvel environnement commercial.
Une autre EE est hors de question. Tout peut être fait en une seule fois. Et bien sûr, le résultat sera équivalent à un cycle. Le code sera alors logiquement plus compréhensible et prouvera réellement notre logique.
Une autre EE est hors de question. Tout peut être fait en une seule fois. Et bien sûr, le résultat sera équivalent à une boucle. C'est juste qu'alors le code sera logiquement plus clair et prouvera réellement notre logique.
Nous attendons un exemple OOP. Et je le vois toujours sous la forme d'une boucle. La logique ne changera pas parce qu'il faudra d'abord déterminer ce qui doit être changé et ensuite s'appuyer sur les décisions que nous avons déjà prises.