Développeurs. format de l'heure dans le terminal MT5 - 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
GetTickCount ? Tout le truc ? Ne sois pas ridicule.
Vos besoins de trading ne correspondent pas aux capacités limitées de GetTickCount.
La question de l'utilité douteuse de la mesure du taux de tic dans une méta est complètement résolue par les possibilités limitées de GetTickCount.
Il n'y a même pas besoin d'argumenter ici, n'importe qui peut résoudre ce problème très rapidement.
Quant aux millisecondes en général et à mes besoins, j'ai plus ou moins justifié mon opinion sur leur inutilité dans MT5.
Tous les calculs sont basés sur les 10 derniers ticks (ou n'importe quel nombre)...
Avec un tick_volume minute, c'est un peu différent) La période est d'un ordre de grandeur plus long.
Si vous passez par les minutes et divisez 60 000 millisecondes par la taille du tick_volume, le taux de ticks reçus dans chaque minute examinée ne serait-il pas précis à la milliseconde près ?
Si nous prenons l'heure actuelle de l'ordinateur local en millisecondes (en utilisant les outils WinAPI), divisons ces millisecondes par le tick_volume accumulé actuel, n'obtiendrions-nous pas le taux d'arrivée actuel des ticks ?
La question de l'utilité discutable de la mesure du taux de tic dans une méta est complètement résolue par les capacités limitées de GetTickCount.
Il n'y a même pas besoin d'argumenter, n'importe qui peut résoudre ce problème très rapidement.
Quant aux millisecondes en général et à mes besoins, j'ai plus ou moins justifié mon opinion sur leur inutilité dans MT5.
hrenfx:
Mais GetTickCount résout complètement ce simple problème. Les millisecondes n'ont rien à voir avec cela.
C'est une bonne idée. Je devrais l'essayer).
Mais avec des millisecondes en temps de tic, ce serait plus facile.
la publicité n'est pas autorisée ici :)
Personne ne vous empêche d'obtenir l'heure actuelle en millisecondes. Le reste est une question de technique.
Vous ne devez pas le lire attentivement :
P.P.S. Personne ne vous empêche de collecter les ticks dans la méta avec des millisecondes (via l'émulation avec GetTickCount). C'est très simple. La question est de savoir si cela est nécessaire.
L'avantage de GetTickCount est qu'il ne nécessite pas de WinAPI dans MQL. Mais son avantage est beaucoup plus fort car l'heure locale n'est pas nécessairement synchronisée avec l'heure du serveur commercial. Et les données sur l'heure d'arrivée du tick doivent être reçues à l'heure du serveur de négociation. C'est pourquoi les millisecondes sont émulées à l'aide de GetTickCount. Ainsi, la précision est plus élevée que si l'on considère la différence constamment flottante entre les deux temps.
Vous voyez, il ne s'agit pas d'un raisonnement théorique, mais d'un commerce pratique.
Et les données sur l'heure d'arrivée du tick doivent être reçues à l'heure du serveur de négociation. Par conséquent, les millisecondes sont émulées par GetTickCount. Ainsi, la précision est supérieure à la prise en compte de la désynchronisation constamment flottante de deux temps.
+ correct.
Mesurer le temps du côté du terminal signifie qu'il y a également un retard dans l'envoi des données.
Et avoir un temps gagné sur le serveur est juste ce dont vous avez besoin.
Stanislav. Mais vous l'avez déjà dans le système pour les commandes. Il suffit de le donner au terminal pour que les commerçants puissent le prendre.
Avec les ticks, le problème n'a pas été résolu au niveau du serveur, c'est pourquoi je ne le mentionnerai même pas.
Vous voyez, quand un tic vous arrive, cela indique qu'une des choses suivantes s'est produite :
1. Si l'offre de niveau 1 a changé (Bid_1) ;
2. Si Bid_1 n'a pas changé, mais que le volume à ce niveau de prix a changé (augmenté/diminué) ;
Si l'offre_1 n'a pas changé, et que l'offre_2 ou le volume au niveau de prix de l'offre_2 a changé ;
etc.
Il en va de même pour le Ask. Et maintenant l'offre, le Ask et les volumes à chaque niveau de prix ensemble. Pouvez-vous imaginer combien de données différentes il y a ? Et tout cela est emballé dans 1c.
Il peut y avoir jusqu'à des dizaines de ces tics en une seconde. Comment les classer ? Le pas de temps en 1s est une classification très grossière, nous avons besoin d'un pas de temps fin - millisecondes. En termes généraux, est-ce clair ?
par exemple sur le retard du serveur et tous les bits et les demandes viendront toujours dans le futur, peu importe combien ils étaient.
comment cela peut-il vraiment aider dans le commerce... ? Je ne l'ai pas encore compris, sauf pour mesurer la volatilité.
Au fait, êtes-vous sûr que tous les ticks avec un taux de millisecondes arriveront de la source initiale à votre moniteur (point visuel final) si le MC ajoute des m.s. ?
J'ai lu l'article et compris que les millisecondes ne sont nécessaires que pour le plaisir. Pouvoir mesurer le prix d'une course de 100 m à la ms près.
sergeev
Donnez-le au terminal pour que les commerçants puissent le prendre.
Pour le leur donner, le type datetime doit devenir 10 octets, et la structure MqlDateTime doit devenir plus grosse.
Attendez MQL6, le minuteur en millisecondes, l'historique des tics et bien d'autres choses encore y apparaîtront. Mais je ne vois pas l'intérêt de l'ajouter maintenant. IMHO.