Organiser le cycle de commande - page 2
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
Parce que le prix va bouger, et à chaque nouvel appel à OnTick, la condition pour une nouvelle modification du même ordre, premier de la liste, sera remplie. Surtout si la modification ne dure que 5 secondes ;)
Une fois encore, la question de la pertinence est abordée. Une commande sera toujours d'actualité. Les autres seront à jour, si possible. Votre variante, en revanche, n'est pas à jour de tous les ordres.
Une telle "colonne vertébrale" briserait la logique d'un EA travaillant avec plus d'un ordre.
A quoi cela servirait-il si cela ne donne aucun avantage aux systèmes avec une commande et gâche les autres ?
J'aimerais comprendre ce que vous voulez dire, mais je ne peux pas. Je ne vois pas où est le problème avec le principe "si le temps d'attente est passé, mettez à jour l'environnement commercial".
Trier par volume et/ou distance par rapport au prix avant de traiter les ordres est la bonne chose à faire. Mais nous ne devrions pas supposer que tous ceux qui copient le code du forum l'implémenteront.
En ce sens, mon code est plus sûr.
Eh bien, il n'a pas été écrit pour les débutants. Vous et moi en discutons très bien ici - pas d'eau.
La question de la pertinence est à nouveau soulevée. Une commande sera toujours à jour. Les autres seront si possible à jour. Votre option est que toutes les commandes ne sont pas à jour.
Réel - de combien ?
Je suis heureux de comprendre ce que vous voulez dire, mais ça ne fonctionne pas. Je ne vois pas de problème avec le principe "si le temps d'attente est passé, mettez à jour l'environnement commercial".
Votre algorithme est fixé sur le premier ordre de la liste, c'est tout.
Dans certaines situations, cela peut être préjudiciable au système (je l'ai rencontré dans la pratique).
Réel - de combien ?
Dans mon scénario, les deux SLs auraient été modifiés à 1.2375 ou au pire, à 1.2374. Conclusion : +30 pips sur les deux ordres.
À chaque étape de votre exemple, le TS devrait savoir où se trouvent ses ordres sans qu'il y ait d'ordre de négociation. C'est-à-dire que le TS ne peut être rattaché d'aucune manière à l'endroit où se trouvent ses commandes actuellement. Il ne s'occupe que de calculer où ils doivent se situer et de synchroniser l'environnement commercial avec ce qu'il a calculé par le biais d'ordres commerciaux.
Dans votre exemple, cependant, le résultat du TS dépend du fait que OnTick soit arrivé au prix haut ou non. Et le TS correct devrait être exactement à la hauteur. Elle voit que ce prix existait (même si le OnTick avec lui a été manqué), et donc ses SLs doivent être placés en conséquence. Et la synchronisation fera son travail à 100%.
Et je ne comprends pas pourquoi vous continuez à dire que le second est immobile. Même sans logique de synchronisation, il sera modifié de la même manière que dans votre variante. Ce n'est pas comme si OnTick était appelé sur l'événement NewTick, mais comme une fonction interne normale.
À chaque étape de votre exemple, le TS doit savoir où ses ordres doivent se trouver sans ordre de négociation. En d'autres termes, le TS ne peut être lié d'aucune manière à l'endroit où se trouvent les commandes actuellement. Il s'agit uniquement de calculer où ils doivent se situer et de synchroniser l'environnement commercial avec ce qu'il a calculé par le biais d'ordres commerciaux.
C'est le cas, elle le sait. Mais elle n'a pas le temps de le synchroniser - pendant qu'une modification passe, le prix bouge encore et une nouvelle condition calculée lui dit de modifier à nouveau le premier ordre. Et cela arrive tout le temps.
Dans votre exemple, le résultat de TC dépend du fait que OnTick soit arrivé au prix élevé ou non. Et le TS correct devrait être exactement avant cela. Elle voit que ce prix était (même si le OnTick avec lui a été manqué), ce qui signifie que ses SLs doivent être placés en conséquence. Et la synchronisation fera son travail à 100%.
Ce n'est pas le cas (dans l'exemple, il n'y avait pas de calcul du niveau SL).
Et la synchronisation ne fera pas le travail, car elle n'aura pas le temps (voir ci-dessus).
Et je ne comprends pas pourquoi vous continuez à dire que le second est immobile. Même sans logique de synchronisation, il sera modifié de la même manière que dans votre variante. Ce n'est pas comme si OnTick était appelé sur l'événement NewTick, mais comme une fonction interne normale.
Comme d'habitude, je l'ai compris.
Cependant, le prix a déjà changé alors que le processus de modification est en cours et l'appel forcé de OnTick fonctionne déjà avec le nouveau prix, alors que le second ordre reste à son niveau initial.
Il n'y a pas d'erreur. Peut-être trop spécifique pour votre situation (mais encore une fois, tout à fait réel, de la vie).
Il le fait, il le sait. Mais il n'a pas le temps de se synchroniser - pendant qu'une modification passe, le prix évolue encore, et la nouvelle condition calculée lui indique de modifier à nouveau le premier ordre. Et cela arrive tout le temps.
L'exemple que vous avez inventé ne nous donne pas de pertes supplémentaires compte tenu de cette logique. Laissez-moi vous donner un exemple.
Supposons que nous trailing BuyLimits après le mouvement à la hausse afin d'ouvrir lors du pullback nécessaire. Almost Lucky-TC. Si nous traînons une montagne de limites à chaque fois, nous ne pourrons pas attraper un pullback avec votre option.
C'est étrange de donner des ordres commerciaux basés sur un environnement commercial dépassé. Mais vous vous entêtez (comme moi) à défendre un point de vue différent.
Il est étrange de donner des ordres commerciaux basés sur un environnement commercial obsolète. Mais vous vous entêtez (comme moi) à défendre un point de vue différent.
Vous devez choisir le moindre des deux maux.
Bien sûr, l'exemple avec la limite s'étendant derrière le prix est mieux à mettre en œuvre dans la variante "1 EA = 1 ordre dans chaque direction".
Mais en général, il est préférable de garder le contrôle de toutes vos commandes.
Mais en général, il est plus correct de garder le contrôle de tous vos ordres.
En d'autres termes, vous n'êtes pas d'accord avec l'exigence selon laquelle le TS doit fonctionner uniquement avec l'environnement commercial actuel.
En d'autres termes, vous n'êtes pas d'accord avec l'exigence selon laquelle le TS doit fonctionner uniquement avec l'environnement commercial actuel.
Si vous devez sacrifier le contrôle de tous les ordres de la CT pour y parvenir - absolument.
Imaginez : vous avez une flotte de quatre camions. Chacun d'entre eux transporte une précieuse cargaison d'un point A à un point B. Vous devez surveiller l'itinéraire.
Que préférez-vous : être en contact 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 léger détour si vous ne les acheminez pas à temps. Mais globalement, c'est mieux pour l'entreprise que de conserver un camion et de perdre les trois autres.
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 une précieuse cargaison d'un point A à un point B. Vous devez contrôler l'itinéraire.
Préférez-vous être en contact 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 léger 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.
+1.
Peut-être que la nouvelle idée n'aurait pas vu le jour avec l'approche OOP, où une boucle analogue à la force brute de l'ordre est cachée dans une entité de type gestionnaire qui, au lieu d'appeler directement OrderModify, génère une commande de modification (avec tous les paramètres) et la place dans une file d'attente qui est ensuite traitée. L'idée est de diviser la responsabilité (qui dans ce code est entassée dans une seule boucle) entre un objet d'analyse de l'environnement et un objet qui effectue des actions basées sur l'analyse.
Peut-être que cette idée ne se poserait pas avec une approche OOP, lorsqu'un analogue de la boucle avec recherche d'ordre est caché dans une entité comme le gestionnaire, qui au lieu d'appeler OrderModify génère directement la commande à modifier (avec tous les paramètres) et la place dans une file d'attente, qui est ensuite traitée. L'idée est de diviser la responsabilité (qui dans ce code est entassée dans une seule boucle) entre un objet d'analyse de l'environnement et un objet d'exécution des actions basées sur l'analyse.
La seule façon d'éviter une telle situation est d'utiliser des commandes asynchrones.
Sinon, il y aurait toujours une boucle sur la liste des commandes à exécuter, qui est, en fait, 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 envoyées hors de la file seraient obsolètes.