Décalage entre backtest et réalité

Bonjour à tous,

Il est souvent écrit que les backtests de prt ne sont pas fiables, que parfois PRT fait des choses étranges et que certains traders ne "retrouvent" pas dans la réalité les résultats avancés par backtests.
Je suis en mesure d'apporter une illustration qu'il peut y avoir des différences entre un backtest et la réalité. Dans l'exemple que je vais donner via un cas réel on constatera que le décalage backtest/réel ne vient pas de prt (qui sur cet exemple est juste) mais de ce que j'appelle "l'alea du réel" (délai entre le moment ou l'ordre est lancé et executé).
Dans un 2eme temps je vous fairais part de ma mesaventure positive de ce jour via prt.

1) Décalage PRT/réel

Depuis un mois environ je trade via proorder par un algo fait maison qui semble bien fonctionner.
Cependant hier (26/07) et avant hier (25/07) j'ai eu sur ces trades réels 2 jours de pertes consécutives. Comme j’essaye souvent d'apprendre de mes erreurs, le soir j'ai "débriefé" mes trades de ces 2 journées, pour voir si des erreurs de trades ont été commis.
J'ai commencé à backetester ces 2 journées......et là surprise : les 2 journées de perte en réel sont en PV sur le backtest.
J'analyse donc ces 2 journées.
Voici ce que j'en retire :

Backtest du 25/07/16

dax 250716 BACKTEST.png (29.99 Kio) Vu 1613 fois

Le 1 er trade est déclenché à 9h11 au cours d'ouverture de la bougie soit 10171,3 et le target est touché sur le plus haut de la bougie (10191,3)
Le 2e trade (short) se déclenche à 9H20 sur le cours d'ouverture de 10167,1 et le target est atteint sur la même bougie.

A ce stade je précise que l'algo n'ouvre une position que dès lors que l'on n'a pas de position onmarket.

Trade réels

Voilà ce que j'ai fait dans le réel.

dax 250716 réel.png (30.26 Kio) Vu 1613 fois

Le 1 er trade s 'est déclenché à 9h11 comme dans le backtest; Mais dans cette réalité, le temps que la machine lance l'ordre et l'execution prenant quelques micron seconde le prix d'achat ne se fait pas au 1er tick d'ouverture (10171,3) mais au tick suivant soit 10172,8 ; le target est donc placé 20 pts plus haut soit 10192,8 (au lieu de 10191,3) .... qui ne sera pas touché, mais par contre le stop loss sera touché à 9h20;
Ce stop de débouclage sur la bougie 9h20 empêche le 2eme signal de trade de se déclencher (ce qui est normal).

Au final le backest indique sur cette partie de journée un gain de 40 pts. dans la réalité j'ai fait une MV 20 pts..... et pourtant les signaux sont les mêmes.

Sur la journée du 26/07 la problematique est la même.


2) PRT : "le soulèvement des machines"

Suite à ces 2 jours de pertes j'avais décidé de ne pas trader aujourd'hui, algo non mis en route.
Ce soir grande surprise : je constate que des trades ont été passés aujourd'hui, materialisant une PV de 60 pts . Les TP correspondent aux target de mon setup.
D'une part mon algo s'est "lancé" tout seul et d'autre part il n'a pas repecté les lignes de code (qui ont toujours fonctionnées jusqu'à ce jour) notamment la fonction strategyprofit qui aurait du l'arreter......mais il a continué à effectuer des trades toute la journée et bien audelà de la strategyprofit.

A noter que l'algo avait été coupe hier par la fonction "quit" et de par cette fonction est placé en "attente" et qu'à chaque fois il faut cliquer dessus, puis sur start pour le relancer le lendemain.

D'où ma question aux inités de prt : est il possible qu'un algo qui est mis en "attente", se déclenche automatiquement si l'on n'a pas cliqué sur "start" (lorsque la veille il est stopé par la fonction quit ?



(je précise aussi que ce soir je n'arrive plus ni mettre en route ni réinstaller PRT ; j'ai du changer de session windows pour réinstaller prt sur une autre session).

Le trade s 'est déclenché Mais (...) le temps que la machine lance l'ordre (...) au tick suivant soit 10172,8 ; le target est donc placé 20 pts plus haut soit 10192,8 (au lieu de 10191,3) ....

Salut G'sT, ne pourrais-tu pas quand il y a un écart de 1.5 là pour l'exemple réduire le tp (fonction intégré) ? Ou plus précisément lui définir que quand tu subis un écart dû à un tick, si l'écart est supérieur à "1point ou autre au choix" tu réduise ton Tp de 20 à 19? Dans l'idée.
Après re-effectuer les résultat de backtest de ton algo non plus avec Tp 20 mais Tp 19 ou autre Tp peut demander du boulot mais pourrait peut-être améliorer ce petit aléas en ajoutant de mini ajustement comme l'idée évoquée.

(lorsque la veille il est stopé par la fonction quit ?

Peut-être une bonne piste. J'espère que tu auras bientôt la soluce.

Pour faire simple, ton code est complètement buggué.

aucune idée d ou peut venir ton pb par contre une solution possible c est de rentrer ton TP en absolue et non pas en relatif, cela t aurai permis de résoudre tes pb de trade

Merci a tous pour vos reponses.


- kero : j avais effectivement pensé a un bug, mais je m interroge comment il a pu survenir dans la mesure ou le code n a pas ete touché depuis le debut du mois (d ailleurs sur prt on voit la date de version ...debut du mois).
Par contre il faut savoir que des qu un algo a une fonction "quit" le programme stop et est bascule de la fenetre "en cours d execution vers la fenetre "en attente". Dans cette fenetre d attente a cote de l algo il y a un triangle "d alerte" qui indique que l algo a ete stope par la fonction quit. Pour le remettre.en route il faut clique sur ce triangle, et a ce momentle triangle est remplace par une icone "start" (toujours ds la fenetre "en preparation". Il faut ensuite cliquer une.2nde fois sur start pour que l algo rebascule dans la fenetre encours d execution et s execute ensuite.
Jusqu a present j effectuai cette operation tous les jours et redemarrais mon algo tous les jours. Il n y a que le 26/07 au soir que je ne l ai pas redemarré et l ai laissé dans la fenetre "en attente".

- Pierre et Darth : merci beaucoup pour votre idee .

Avec le nez dans guidon, je n avais pas vu le pb sous cet aspect...
J avais.envisage de mettre un TP de 18 au lieu de 20, mais les backtest donnait des resultats totalement differents avec 18 plutot que 20.
Alors selon votre idée je vais me pencher sur hypothes d un TP= open de Bougie +20 (au lieu.de TP=20).
Ca semble tout simple mais parfois on ne voit pas ce que.l ont a sous.le.nez.


J ai relance l algo hier soir (version habituelle du debut du mois), on va voir comment il se comporte aujourd hui.


Merci.

G'sT, est-ce que dans ton backtest tu as intégré soit le spread soit les frais ? Sur des trades à petit TP/SL, ça fait toute la différence où un trade gagnant en théorie est en réalité perdant.

Pour le deuximèe point : Pouirquoi la stratégie a continuer de fonctionner :
1) Appel prt
2) Appel ig
3) Soit il y un bug sur l'interface Probuilder ou une erreur de communication qui fait que le status affiché sur ton PC n'était pas le bon.
Soit il y ades gremlins qui trainent dans les DC

Alors selon votre idée je vais me pencher sur hypothèse d un TP= open de bougie +20 (au lieu.de TP=20).

Avec cette solution, le cours se fermera en clôture de bougie, et non quand la condition est respectée. Tu peux avoir des +22 comme des +16 pts avec ce système.

Par contre comme le précise Falex, as-tu bien tenu compte du spread dans ton backtest ?

Merci et Falex et stark.
Falex, mes SL/TP sont larges. Pour backtester les 2 j, je n'ai pas attaché d'importance au spread. Il n'a pas eu d'impact dans mon setup.
J'ai backtesté pour controler les déclenchements de signaux.
Il sont justes sur le backtest, et ce sont les même signaux en réel.
La différence de entre backtest/réel est lié au fait que le backtest prend le trade sur un cours figé et qui correspond à au cours d'ouverture de la Bougie (en h00mn00s), alors que le même signal en réel est prix sur un cours en mouvement soit pour illustrer à h00mn01s.
Mais sur le principe celà n'a jamais été trop perturbant (à l'exception de lundi et mardi ou j'ai pu clairement en voir des limites...).

Pour mon 2e point, je crois bien que j'ai un vilain gremlins sur mon PC.
Je me demande si j'ai pas "choppé" un truc sur mon PC. J'ai presque honte de l'avouer, mais mon antivirus est périmé
Je vais me dépecher de le mettre à jour et nettoyer mon pc....

Cet algo est un "maillon beta" que je vais transposer sur mon fameux indicateur "G'st Snipe Scalp VA" (tu sais celui sur lequel nous avions déjà échangé et ou j'avançais une théorie de "faire peu de trades mais à fortes probabilité" ==> j'envisage de relancer cet indicateur et le finaliser pour la rentrée après mes vacances....à suivre..

Avec les points que j'ai gagné auj + les 60 pts d 'hier m'ont permis de récupérer les 3/4 de ma MV de lundi+mardi. La semaine est un petit peu négative, mais c'est pas grave le mois est positif.
J'ai décidé de ne pas trader demain pour garder le mois en PV, dans la mesure où demain est le dernier jour de trading du mois (j'ai quand même trouvé la 2e quinzaine de juillet pas facile à trader...)

Demain soir je suis en congé, et je pense que je reviendrais pour la rentrée. Je pense que les vacances vont me faire du bien après cette année particulièrement difficile.

Tiens Falex en avant-première la courbe de gains que pourrais donner mon indicateur "G'sT Snipe Scalp VA" sur la période backestée du 22/04/16 AU 28/07/16 sur la base d'un dax à 5 pts :

G'sT Snipe Scalp VA.png (32.3 Kio) Vu 1014 fois

Bonne vacances.

Tu sais moi et les anti-virus .... Ça fait deux

C'est le genre D' équity que j'ai adorée trace lors de mes recherches de backtest

Pour info j ai laissé hier soir mon algo dans la fenetre " en attente" apres son arret d hier sur la fonction "quit" et ne l ai pas redemarré dans la mesure ou je ne trade pas auj.
Au final il n a pas demarré ce matin (ce qui m apparait normal) contrairement au bug d avant hier. Avec le fonctionnement normal d hier, les choses me semblent etre rentrees dans l ordre.

Sans vouloir insisiter ni te commander, tu as demandé à prt et ig de mener l'enquête sur le pourquoi du trade de mardi ? car c'est louche ton histoire.

Quand je regarde ton equity, ton backtest t'annonce 3700points en 3 mois.

FAis un moi plaisir et rajoute les frais/spread, sincèrement ... même si tes TP sont éloigné, sinon tu va avoir la frustration classique de : Ben pourquoi est-ce que je fais que 800pts au liex de 1000 ...
Tu es un homme intelligent et éclairé, mais par moment n'importe qui peut oublier ce genre de détail.
Je prone et insite pour que les backtest de n'importe soit le plus proche de la réalité, sinon on se jette de la poudre aux yeux.
Les frais de transaction sont un vrai facteur pour passer d'un côté gain à un côté perte.

Je suis d'accord avec Falex pour le spread, car tu verras peut-être que des fois ton TP n'aura pas été déclenché à cause du spread (et donc transformé un gain en perte), ton stop aura été frôlé dans ton backtest, mais en vrai avec le spread il se serait déclenché, ...

Sinon félicitations pour tes résultats, cela a l'air très bon

Je regarderai pour le spread ce soir si je peux et je posterai la courbe.

Ce n est pas 3700 pts qu il fait en 3 mois me semble t il mais ( 18008-10000) /5= 1600 pts soit une moyenne de d environ 500 pts/mois.

Et encore ce qui etait valable sur ce trimestre ne l a pas ete forcement pour le trimestre precedent et ne sera peut etre pas vrai pour le trimestre a venir
Si ne.n en fait que la moitie j en serais super content deja.

La pour l instant la courbe n est pas encore affinee.
La courbe.est brute et rassemble l.ensemble des trades des patterns deceles (on va dire une vingtaine /j).
Le principe de mon indicateur "snipe" est de ne faire qu 1/10e de ces trades (les meilleures) comme un sniper...

Dans la version test actuelle la notion de rendement en pts ou euros ne m importe pas; pour l instant je planche sur le taux de reussite par une approche des probabilites.

Apres viendront.les autres etapes de rentabilite et de MM.

Si je n arrive faire que 200 pts avec je serais tres heureux (rappelles toi dans ma version originale de snipe l annee derniere, je n etais dans l attente que de 100 modestes points).

Ah ok j'avais pas vu que tu avais mis le 0 à 10 000.

Pour les frais dans le backtest, farfouille dans le forum je l'ai expliqué plusieurs fois.

Soit tu renseigne spread soit frais de transaction.
Seul bémol, tu ne peux indiquer un spread par plage horaire. Je partais du principe que la majorité de mes trades étaient exécuté pendant la période cash.

Ok merci Falex.
L ensemble des trades sont realises dans la periode de cotation du cash (j ai code une plage de trading de 9h a 17h30).
Je partirai.sur la base d un spread de 1.

Retrouvé : prt-comment-regler-le-bouton-gestion-de ... t2434.html
Le post date un peu j'avais du le faire pour la v9 mais l'idée est toujours la même.

Je vais voir si j'en trouve un pour la v10.

pas retrouvé.
De mémoire dans la V10 il y a en plus une case spread.
Donc soit tu indiques le demi spread (ou le spread entier je ne sais plus) donc 0,5 ou 1 pour le DAX/CAC/indice anglais
Soit tu met juste des frais de transaction par lot : 1€ pour le micro DAX, mini CAC, 5€ pour le mini DAX, 10€ le full CAC ou 25€ pour le full DAX.

avec du recul c'est peut-être plus interessant de mettre le spread, comme si si tu fais tourner sur n'importe quelle contrat, c'est prt qui se débrouille avec la valeur en point.

A l'époque je ne faisais un backtest par sous-jacent avec les bon réglages.

Le plus prise de tête étant le Forex avec sa "virgule décalé".