Bibliothèque: OnTickMulti - 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
fxsaber #:
À quoi sert cette ligne ?
À quoi sert cette ligne ?
Pour renvoyer la valeur du solde souhaité.
Avez-vous vérifié dans quelle mesure les ticks de votre solution sont synchronisés dans le temps ?
Lors de tests classiques, si l'on interroge les ticks à partir de différents symboles, on constate un décalage d'un tick les uns par rapport aux autres. Pour vérifier cela, j'ai créé des scripts personnalisés avec des ticks toutes les minutes.
Avez-vous vérifié dans quelle mesure les ticks sont synchronisés dans votre solution ?
Tout fonctionne correctement. Et cela fonctionne également correctement dans le testeur d'origine. Si ce n'est pas le cas, montrez-le-moi.
Dans le testeur d'origine, c'est correct. Si ce n'est pas le cas, montrez-le.
J'ai créé des ticks personnalisés à partir des minutes de l'EUR et de la GBP (pour plus de commodité)
Pour l'EUR, c'est correct ; pour la GBP, c'est un tick en avance (regardez l'heure et le cours)
J'ai créé des graphiques personnalisés à partir des données de l'EUR et de la GBP (pour plus de commodité)
C'est correct pour l'EUR, mais pour la GBP, c'est un tick en avance (regardez l'heure et le cours)
Les ticks ayant le même horodatage n'arrivent pas simultanément. Ils se succèdent les uns après les autres. Et si un tick sur l'EURUSD avec un horodatage plus élevé arrive en premier, on ne sait alors rien, à ce moment-là, du tick ayant le même horodatage sur le GBPUSD, qui arrivera en second. Par conséquent, au moment où arrive le premier tick EURUSD, le deuxième tick GBPUSD n’existe tout simplement pas ; on dispose uniquement des données du tick GBPUSD précédent.
Dans le testeur, c’est un inconvénient : pour l’arbitrage, il faut que les données soient synchronisées.
Et pas seulement pour l’arbitrage. Si le système repose sur la corrélation entre les instruments, cela revient à anticiper l’avenir.
Dans le testeur, c'est un inconvénient ; pour l'arbitrage, il faut que ce soit synchronisé.
Et pas seulement pour l'arbitrage. Si le système repose sur la corrélation entre les instruments, cela revient à prédire l'avenir
Dans ce genre de cas, il existe un délai d'exécution configurable dans le Testeur.
Dans le testeur, c'est un inconvénient ; pour l'arbitrage, il faut que ce soit synchronisé.
Et pas seulement pour l'arbitrage. Si le système repose sur la corrélation entre les instruments, cela revient à prédire l'avenir
Il n’y a pas d’anticipation de l’avenir, car si, à l’instant X, il existe des ticks pour plusieurs symboles, alors en même temps que le 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:04 était avant 00:05, et non après).
Pour assurer la synchronisation, il faut la mettre en œuvre de manière algorithmique dans votre code ; par exemple, dans le gestionnaire OnTick, 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.