Les palmes dans le verre - essayer de comprendre ce qui s'est passé par les tiques - page 13
![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Laissez-moi vous donner un petit aperçu))
En plus des trois types d'ordres, il existe quatre types d'ordres sur le FORTS.
C'est une situation très possible. Sur les marchés hautement concurrentiels, les offres arrivent par dizaines par seconde, il n'est donc pas étrange que deux offres correspondent avant de former les niveaux Ask/Bid.
C'est vrai. Nous ne voyons que la pile (demander/offrir)
car l'échange nous le "donne". Il ne s'agit pas d'un flux en temps réel.
Malheureusement, MT5 ne diffuse pas un flux d'offres impersonnel,
donc il est impossible de reconstruire l'historique complet des échanges et
pour savoir exactement comment les transactions étaient exécutées dans le noyau d'échange.
Sur la place 2, il y a deux possibilités de former un taux de marché.
1. la bourse envoie le SRES des ordres en cours (coupe agrégée, ce que nous voyons dans le terminal).
2. Nous pouvons former le bloc à partir du flux d'ordres impersonnels.
La deuxième variante n'a aucun sens à notre vitesse (c'est probablement la raison pour laquelle MT5 ne transmet pas les ordres (journal des ordres).
Il est clair que l'hypothèse d'une convergence super rapide des ordres et d'un envoi unique semble donc plausible. Cependant, je pense que les collègues seront d'accord pour dire que cette convergence des ordres doit se produire avec une certaine fréquence et non de manière aléatoire.
Par exemple, dans le fichier joint au premier post, nous pouvons trouver une telle zone
ici nous voyons au tout début, que les transactions ont été ajoutées de 13:00:00.013 à 13:00:00.341, au même moment de nouvelles Ask sont apparues seulement à 13:00:00.445 , il s'avère que l'addition a été plus longue que le nombre de transactions, supposons que c'est une fenêtre, qui est de 432 millisecondes.
Mais, ce que nous voyons ensuite - la fenêtre suivante pour les transactions était ouverte de 13:00:00.603 à 13:00:01.095 et durait 492 000 secondes - eh bien, laissez faire, l'écart n'est pas grand.
Regardons le créneau suivant de 13:00:01.437 à 13:00:04.023 et c'était, attention, 2905 millièmes de seconde, soit presque trois secondes ! !!
Par conséquent, l'hypothèse d'un matage ne semble pas tenir - probablement les valeurs réelles de Ask et Bid diffusées par la bourse ne sont pas prises en compte !
Par conséquent, l'hypothèse du matage semble être invalide - il est probable qu'en fait les valeurs Ask et Bid diffusées par la bourse ne sont pas prises en compte !
Vous vous entêtez à utiliser des données incomplètes, sans une bande de soumissions toutes les hypothèses ne valent rien !
Vous vous entêtez à fonctionner sur des données non COMPLÈTES, sans bande d'applications - toutes les hypothèses sont nulles et non avenues !
Justifiez, s'il vous plaît. Nous disposons d'informations sur les transactions consolidées.
Et en quoi la bande d'ordres est-elle utile ? Que voulez-vous dire exactement par là - un moulage complet de la coupe ?
Justifiez, s'il vous plaît. Nous disposons d'informations sur les transactions consolidées.
Et, en quoi cette bande d'appel d'offres est utile ici ? Qu'entendez-vous exactement par là - un moulage complet du verre ?
Alexey !
C'est très simple !
La bourse reçoit des demandes (3 types)
Une heure d'arrivée leur est attribuée et ils sont stockés dans la mémoire cache jusqu'à ce que l'heure d'arrivée soit atteinte.
La vente aux enchères, au cours de laquelle les offres sont additionnées, rejetées ou inscrites dans la coupe.
La vente aux enchères ne se déroule pas en temps réel, mais par tranches.
Les offres sont empilées, par exemple 100 offres ou sur une minuterie (je ne peux pas le dire avec certitude).
Ensuite, la coupe remplie (SRES) nous est transférée.
De la bande des offres, qui va pratiquement en temps réel, la coupe et de la bande des transactions,
qui est transmis après l'enchère, nous pouvons voir l'image complète de la transaction.
Sans la bande des offres - le tableau n'est pas complet (les offres à l'enchère sont résumées ou rejetées sans générer une demande/une offre).
nous sommes arrivés au tumblr et à la bande des échanges qui ont été formés APRÈS la vente aux enchères.
C'est clair maintenant ?
Si cela ne change rien et n'affecte rien, alors ne le prenez pas en compte.
Il y a un verre et les accords glissent après lui. C'est avec cela que nous devons travailler.
une vente aux enchères au cours de laquelle les offres sont consolidées, rejetées ou mises dans un tumbler.
Et puis il y a ça. Il s'avère que les offres peuvent être consolidées en dehors de la coupe.
Je vais ajouter.Est-ce que ça existe ?
Supposons que nous ayons des informations sans l'éclat.
Alors j'ai une question. Le volume de ces informations apparaît-il quelque part ?
Dans des rapports.
Avez-vous besoin de cette alimentation ?
Si elle ne change rien et n'affecte rien, alors elle ne doit pas être prise en compte.
Il y a un marché et après lui - les affaires se nourrissent. C'est avec cela que nous devons travailler.
Et puis il y a ça. Il s'avère que les applications peuvent être consolidées indépendamment du verre.
J'ajouterai.Cela arrive-t-il ?
Supposons que nous ayons des informations sans l'éclat.
Alors j'ai une question. Le volume de ces informations apparaît-il quelque part ?
Dans des rapports.
Je vais me permettre de répondre. C'est simple : ce qui est dans la coupe est l'offre, ce qui vise à conclure un accord est la demande. A son tour, la demande peut être satisfaite, dans ce cas c'est une affaire qui est affichée dans la bande, ou elle peut être insatisfaite (par exemple, à cause du manque de volume), dans ce cas elle n'est pas reflétée dans les "informations d'index" et dans la bande. Plus haut, il a été dit que la bourse agrège les informations relatives aux ordres/ordres. C'est probablement le cas, car toutes les actions sont discrètes. Selon quels critères - je ne le sais pas.
P.S. Il n'y a pas de "bandes de commande" dans les informations en échange ouvert. Sur les plateformes d'échange professionnelles, vous pouvez en tenir compte en fixant les variations du volume de l' offre à certains niveaux. Mais d'après mon expérience, cela ne vous apportera pas grand-chose.
Ce fragment de commande est-il vraiment nécessaire ?
Si cela ne change rien et n'affecte rien, nous ne devons pas en tenir compte.
Il y a un verre et les accords glissent après lui. C'est avec cela que nous devons travailler.
Et aussi ceci. Il s'avère que les offres peuvent être résumées en dehors de la coupe.
Je vais ajouter.Est-ce possible ?
Supposons que nous ayons des informations sans l'éclat.
Alors j'ai une question. Le volume de ces informations apparaît-il quelque part ?
Dans des rapports.
Les demandes sont reçues par la bourse (3 types)
Une heure d'arrivée leur est attribuée et ils sont stockés dans la mémoire cache jusqu'à ce que l'heure d'arrivée soit atteinte.
Enchères, où les offres sont additionnées, rejetées ou mises en jeu.
La vente aux enchères ne se déroule pas en temps réel, mais par tranches.
Les offres sont empilées, par exemple 100 offres, ou sur une minuterie (je ne peux pas le dire avec certitude).
Ensuite, la coupe remplie (SRES) nous est transférée.
De la bande des offres, qui va pratiquement en temps réel, la coupe et de la bande des transactions,
qui est transmisaprès l'enchère, nous pouvons voir l'image complète de la transaction.
Sans la bande des offres - le tableau n'est pas complet (les offres à l'enchère sont résumées ou rejetées sans générer une demande/une offre).
nous sommes arrivés au tumblr et à la bande des échanges qui ont été formésAPRÈS la vente aux enchères.
C'est clair maintenant ?