J’ai fini la programmation de mon algo avec effet “mitraillette”. Au passage merci pour ton aide lors de l’élaboration.
Je l’ai donc mis en route en démo puis en réel mais je m’aperçoit que le rapport détaillé du backtest et la réalité ne sont pas conformes (voir Screenshots).
En backtest, toutes les positions avec zéro barres et un gain n’hésitent pas en réel. Le gain, est pourtant comptabilisé dans le rapport détaillé. Autre bog, de part la conception du code, la dernière entrée qui doit forcement être en négatif pour que le trade prenne fin, mais elle n’apparaît pas non plus.
Le réel , lui corresponds à ce que j’ai écrit. Comme j’utilise les backtests pour l’écriture et l’optimisation ça complique vraiment la tache…. C’est même impossible. J’ai besoin d’un backtest sensiblement fiable pour pouvoir finaliser.
C’est la première fois que j’ai des différences aussi importante entre réel et backtest.
Vois tu des corrections à faire dans mon code pour que les résultats des backtests soient plus fiables ? ( Itf joint)
Ps: Je m’étais déjà aperçus que la normalisation des tailles de positions (en euros) fausser complètement les optimisations. Mais dans ce cas même en mettant le nombre de contrat sur “1” j’ai les mêmes différences entre réel et Backtest, je comprends plus.
Je n’ai pas regardé ton code, mais d’emblée, petit rappel :
les backtests doivent être réalisés en mode tick par tick pour obtenir l’écart le plus faible possible entre ce qui aurait put se passer en réel et le backtest (la réalité dépassant la fiction si je puis dire ..)
les optimisations ne sont pas faites en mode tick par tick, même si la case est cochée
si problème d’ordres non ouverts, toujours vérifier la liste des ordres à la fois dans la plateforme et chez le courtier pour déceler des erreurs d’ouverture (elles sont toujours répertoriées)
les ordres conditionnels doivent respecter la “limite au stop” imposer par le courtier
1 Je backtest toujours en mode tick par tick. Mais il est vrai qu’en réel dans ce cas il y a une fermeture et une ouverture dans la même bougie…. on dirait que le mode tick par tick n’est pas respecté….mais on est en réel donc c’est carrément fou !
2 Bon à savoir pour les optimisations
3 Je t’ai joins la liste des ordres, rien en anomalie. pour autant on observe que la position perdante à été prise à 15h22 après la clôture de la première position chose qui n’aurait pas dût se passer….
4 Dans mon code j’ai inclus pour la première position une tailles Minimum afin de respecter la limite de 6 pips de IG pour le Dax. je l’ai fixé à 7 pips pour être sur d’être dans les clous. J’ai aussi une taille maxi pour éviter de me retrouver avec un SL trop grands mais ça ne devrait pas influencer. Concernant les positions de renforcement non pas de limite mini et maxi mais c’est voulu. Dans ce cas là j’ai vérifié et le plus petit SL devait faire 7,3
Bref, c’est vrai que cette stratégie repousse les limites, pour autant elle ne devrait pas boguer comme ça. c’est très étrange.
je pense qu’il y a une correction à apporter, please help
Ces trades sont fermés avec des ordres conditionnels STOP. Les paramètres du backtest sont-ils exactement les mêmes que ceux du réel ? Par ailleurs, les calculs semblent dynamiques, si les ordres précédents étaient décalés pour X ou Y raison, est-ce que cela n’influe pas les calculs ? (désolé mais ton code est “dur” à comprendre 😉 )
J’ai une théorie…on voit dès le départ que entre le backtest et la réalité il y a un décalage de une bougie et +- 0.3 pip de différence . Donc dans la réalité mon niveau de Be est déclenché et on stop le trade. Dans le backtest, le niveau de Be n’est pas déclenché et ça explique la différence l’un continue, l’autre est sortie à BE+”point to keep”. Ça se joue juste à cause de ce décalage au départ
Dans ce cas, la deuxième position en réel (celle qui est en perte sur la liste des ordres), elle certainement dût au fait que le premier robot à reçus un nouveau signal. C’est donc une nouvelle position et non un renforcement. Mais dans ce cas, pourquoi ma position à telle était stoppée +ou- au niveau du Be de la premier position ???
Il est clairement dit:
1
2
3
4
IFNOTONMARKETTHEN
breakevenLevel=0
breakeven=0
ENDIF
Dans cette hypothèse, cette position aurait dût être gagnante car le niveau de SL n’a jamais été atteint….
Pourrait tu confirmer cette hypothèse ou alors il n’y a pas eu respect de l’algorithme. Avec la chronologie de la liste des ordres , on voit clairement que le second ordre a été pris après que le premier soit clôturé.
Dans tous les cas il s’est passé quelque chose qu’il va falloir corriger. C’est soit dans mon code, soit au sein de Pro-Order IG.
En l’attente de te lire.
Ep Pj le détail des opération IG conforme à celui de PRT
J’ai fait un copier coller de l’algorithme dans la fenêtre Pro-Order de prt. On est sur le Dax donc spread fixe à 1 . On est strictement sur le même algorithme dans les mêmes conditions , j’explique même pas qu’on ne démarre pas sur la même bougie, franchement il y a un 0,5 au royaume des 1 et des 0…..
Mon code dit: Si il y a un signal du premier robot et que close – donchian est supérieur à 7 alors on achète ou on vent. On défini le SL entre abs(close – Donchian) . Le nombre de contrat à acheter et alors égale à 7 euro/valeur du SL. Si on atteint le niveau du breakeven+”point to keep” on pyramide très agressivement et on sort au niveau be+ point to keep du panier (Positionsize). Le breackevenLevel et déclenché par les highs ou les lows pour plus de réactivité.
Pour être sur, j’ai essayé de changer les date du bactest on à toujours les mêmes position au mêmes endroits.
A mon avis, il faut vérifier comment la lecture du code s’organise, puisqu’il est lu de haut en bas, et une seule fois par bougie.
Donc pour le cas du deuxième ordre ouvert et fermé dans la même bougie, je pense qu’une ou plusieurs variables n’a pas eu le temps (ou l’occasion plutôt) de se mettre à jour entre la fermeture du précédent ordre, l’ouverture du nouveau et les calculs de stop suiveur, breakeven, pyramide, etc…
C’est justement pour faire des tests plus souvent, qu’on utilise maintenant le MTF. Le code est certes toujours lu une seule et unique fois par bougie, mais on peut le lire aussi 5 fois dans une bougie de 5 minutes, en lançant le code dans un TF de 1-minute. Cela aura pour conséquence d’updater les variables plus souvent et éviter ce genre de problème..
Oui je comprends, effectivement ça augment les chances que les variables soient à jour…. mais quelle boulot hahaha.
Pour l’instant je n’ai fais qu’une seul stratégie en MTF et je suis loin de maîtriser le sujet ;-). Dans cette première stratégie j’exploite le MTF pour mettre en corrélation plusieurs indicateurs sur différents TF, mais je ne décompose pas une stratégie M1 en 12 secondes pour avoir 5 fois plus de réactivité.
1 Le 12 secondes est-il disponible en MTF ?
2 Pourrais-je abusé de ton temps? Peux-tu me donner au moins la trame d’un telle algorithme ? et aussi, j’ai aucune idée de ce qui doit rester en M1 et ce qui doit passer en S12.
Si les conditions de trading sont en M1, alors elles doivent y rester. En général on veut updater le management des ordres rapidement, et là on descend dans les TF.
Quelques liens en vrac de stratégies MTF du forum :
oui je sens que je vais avoir besoin de courage….. 😉
Je viens juste de penser une chose, ma stratégie est un M1 certe c’est un fait, mais j’ai du faire face à deux problèmes dans ce cas précis.
1 C’est très certainement la variable “breakevenLevel” qui n’est pas redescendu à zéro entre les deux positions et je me fais sortir de la deuxième au niveau “breakevenLevel” de la première. Donc passé le trailling stop en s12
2 Mais il y a aussi le problème que je démarre la première position avec une bougie d’écart entre réel et backtest…. Si c’est à cause d’une variable d’un de mes filtres autant tout passer en S12 et garder que le croisement du TDI en M1 ?
.
.
