Le temps d'exécution est l'ennemi des baktests des algos

[trappiste73]

Le temps d'exécution en réel est l'ennemi des baktests des algos.

PRT insiste bien : « lors d’un backtest, les prix d’exécution des ordres sont estimés depuis les données historiques afin d’être aussi proche que possible d’une exécution réelle sur le marché ».
Proche oui mais pas équivalent. La différence avec le réel : le temps d'exécution d'un ordre.

ProOrder est du trading automatique et non haute-fréquence : aucune garantie n'est donnée quant à la vitesse d'exécution des ordres donnés par un algo.

J'ai eu le cas sur un algo qui tournait sur 2 comptes. Il s'est exécuté à 13h00min 01sec 680c sur un compte et à 13h00 min 01sec 406c sur l'autre. Une différence qui a conduit l'algo à aller au tapis à cause du slippage de plusieurs points que cette différence a entraîné. Il n'a pas atteint son TP et a fini en SL. Cela a été ma plus grosse perte 2021.

Les backtest d'algos sont donc malheureusement à prendre avec des pincettes. Il faut du coup à la fois réduire son levier, sa perte max et simuler en démo tout algo lancé en réel pour pouvoir vérifier son fonctionnement.

Une sacré limite ...

[Francis1]

[HellionReign]

[falex]

Ça me rappel des échanges sur le sujet avec Kero (il me semble, ou un membre avec pseudo du style Juno…) qui avait déjà relevé cette limite il a quelques années.
Regarde dans le forum , il y a peut-être des éléments intéressant en complément.

Est-ce que cela remet en cause ton utilisation de pro-order ?

-
Marrant ta remarque sur le temps d’exécution car en fait j’ai le même problème sur un programme qui récupère les bougies UT1 à la clôture de celle-ci.
J’ai une fonction de « synchro » pour déclencher la récupération de la bougie à :00secondes mais en pratique mon programme va mettre aléatoirement quelques micro a milliseconde à se déclencher. Et après j’ai le problème du temps de transit sur internet et du traitement par les serveurs en face.

Je pense qu’il faut intégrer cette variabilité d’exécution/réaction car à moins d’être chez le brocker directement on est obligatoirement tributaire de ce genre de problème.

[trappiste73]

Je ne sais pas encore si ça remet en cause mon trading auto mais c'est une sérieuse limite.
Je ne vois pas bien comment l'intégrer dans le code : le slippage peut être négligeable dans 99,99% des cas et très important exceptionnellement. Pro-order ne garantit aucun délai d'exécution.
La seule possibilité viable est de simuler parallèlement en démo pour pouvoir intervenir manuellement en cas de dérapage. Encore faut-il être devant ses écrans lorsque le pb survient ...

[Benoist Rousseau]

la prochaine version de PRT va arranger cela, tu peux m'écrire si tu veux en savoir plus, je ne peux pas donner les détails publiquement pour le moment, c'est en BETA testeur

[ChristelleP]

[kelly]

Bien coder un système n'est pas facile du tout ! Plein de causes de différences entre backtest et réalité.
Tu soulèves un cas très particulier car finalement, les algos impactants, on ne les croise pas si souvent , me semble-t-il sauf en ce moment de période de crise.
Perso, le système que j'ai écrit est sur du UT15' avec TP et SL très lointains ce qui permet d'éviter les brusques variations.
Pour rappel ce système est un "Graal" : 85% de positif ! mais pour 1% annuel de gain en 2021 Non, vous aurez beau le réclamer à corps et à cris, je ne le vendrai à personne et surtout pas à mes amis !
Je ne vois pas comment lutter contre les algos hedge fund depuis nos stations avec des temps de transmission longs (et chez moi "très longs").
Si PRT peut améliorer c'est bien (cf Benoist) mais de toute façon , on ne pourra pas atteindre leur vitesse donc en système automatisé ... ils auront toujours le premier/dernier mot.
Avis perso.

[ChristelleP]

Ne pas lutter contre les algos, mais aller dans leur sens.