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
Il n'y a pas d'anticipation, car si, à l'instant X, il existe des ticks pour plusieurs symboles, alors, parallèlement au premier événement sur l'un des instruments, les autres symboles (pour lesquels les événements sont encore en file d'attente) afficheront le tick précédent, et non le tick suivant (comme dans l'exemple, 00 h 04 précédait 00 h 05, et non l'inverse).
Pour assurer la synchronisation, il faut la mettre en œuvre de manière algorithmique dans le code ; par exemple, dans le gestionnaire OnTick, il faut interroger l’heure des ticks sur tous les symboles concernés avant de lancer une transaction. Mais, en principe, si l'arbitrage porte précisément sur les ticks (et non sur les barres ou les minutes), il est difficile d'imaginer une synchronisation fiable, car les ticks sur certains instruments peuvent en réalité être absents pendant plusieurs secondes.
Tout est relatif : pour un instrument, il y aura un retard, tandis que pour un autre, il y aura une avance.
Tout varie ; dans le débogueur, tout est synchronisé, même avec une fonction OnTick presque vide.
Il faut convertir les barres en ticks pour le test, afin de simuler correctement les commissions et les spreads.
C'est ce qu'il a fallu faire dans OnTick pour que les calculs du testeur personnalisé concordent avec ceux de MT.
Pour assurer la synchronisation, il faut la mettre en œuvre de manière algorithmique dans votre code ; par exemple, dans le gestionnaire OnTick, interroger la fréquence des ticks pour tous les symboles concernés avant de lancer une transaction.
Je crains que cela ne permette pas à la fonction OnTick de détecter que la série de ticks correspondant à l'heure actuelle est terminée. Seul un OnTimer en millisecondes devrait, selon toute vraisemblance, résoudre le problème.
Tout est relatif : pour un instrument, il y aura un décalage, tandis que pour un autre, ce sera un dépassement.
Je crains que cela ne permette pas à OnTick de détecter que la série de ticks correspondant à l'heure actuelle est terminée. Seul un OnTimer en millisecondes devrait permettre d'y remédier.
Tout dépend de la façon dont on écrit la condition dans la boucle « if » en fonction du temps : il faut utiliser le signe « > » strict, et non « >= », et ne pas prendre en compte le tick qui a déclenché la condition.
Avec un minuteur, ça marchera de la même manière.
Je ne comprends pas.
À première vue, avec une identification de l'heure à la milliseconde près (il en va de même pour les secondes) :
Mais je le répète encore une fois (pour Rorschach) : la synchronisation sur des intervalles aussi courts est illusoire. Les ticks d’un instrument donné peuvent être absents pendant plusieurs secondes, auquel cas le cours qui leur correspond peut en réalité devenir « obsolète ». Si, pour certains, il est important que tous les cours correspondent à la même [milli]seconde, il faut alors, dans l'extrait cité (dans le bloc d'analyse commenté), vérifier en plus que les instants des ticks coïncident et ne passer des ordres que si cette condition est remplie.
À vue de nez, avec une identification de l'heure à la milliseconde près (idem pour les secondes) :
Cette méthode ne permet en aucun cas de garantir l'actualité des ticks de tous les instruments. Seul un OnTimer en millisecondes permet de le faire.
Stanislav Korotky #:
Что подразумевается под актуальностью (этот метод отдает последние известные тики по всем инструментам)?
Il n'y aura plus de ticks avec la dernière heure connue.
Et en quoi OnTimer donnera-t-il un résultat différent ?
L’OnTimer en millisecondes garantit que toutes les mises à jour se sont écoulées AVANT cet événement de temporisation. Autrement dit, les mises à jour sont à jour pour tous les symboles.