Attentions les Backtests PRT sont surévalués !

• 03/27/2016 at 4:42 PM #4461
  zilliq

  Bonjour à tous,

  Petite reflexion du dimanche,

  Nicolas en a parlé, a priori sur le forum anglais, mais je trouvais intéressant de développer et préciser l’un des gros problèmes de Backtest sur PRT (en plus de l’absence de Walk Forward, de notions importantes MAE/MFE sur lesquelles je reviendrai à l’occasion)

  En effet, de manière générale, les backtests sont beaucoup trop généreux avec PRT et donc malheureusement peu exploitable et je le déplore

  En effet, prenons un exemple simple, une stratégie basique avec un spread de 1 sur le DAX ET SURTOUT un Stoploss de 1 point et un TP de 25 (peu importe) (Pour le test)

  En pièce jointe, on voit que sur le backtest les résultats sont fabuleux = près de 82 % de positions gagnantes ! 30 % de gains en 2 jours environ ! Whaou !

  Mais car souvent il y a un MAIS quand c’est trop beau, quand on regarde un trade en détail parmi tant d’autres on voit que le Backtest PRT prend systématiquement en compte le Take profit, ici de 3 (va savoir pourquoi pas la totalité), et pas en compte le Stop loss de 1 qui aurait donc peut être été touché (tout dépend si c’est le SL ou le TP qui a été touché en premier)

  Et par conséquent à ne prendre en compte que les TP avant les SL les résultats sont beaucopup trop généreux et inexploitable. Alors ATTENTION quand vous faites des backtests

  Il est vraiment urgent que cette correction fasse partie de la prochaine version de PRT, voire même avant !, en plus des nombreuses améliorations espérées

  La correction ne doit bien évidemment pas prendre en compte le SL AVANT le TP car on va avoir des résultats erronés vers le bas

  Ce qu’il faut c’est backtester dans une unité de temps inférieure en parallèle par ex le 10 s pour le 1 mn comme ici et ainsi voir qui a été touché en premier, le SL ou le TP

  En espérant avoir été suffisamment clair et en espérant une correction urgente

  Bon week-end Pascal

  Zilliq

   

  __________________________________

  Coding is not a crime 😉

  http://www.zilliqtradingresearch.fr/

  __________________________________

   

  

  zilliq

  Participant

  Topics: 58

  Replies: 683

  Been thanked: 152 times
  03/27/2016 at 4:48 PM #4465
  zilliq

  Pour le fun, je fais tourner cette “fabuleuse” stratégie en trading auto sur compte démo pour comparer le backtest avec la réalité

  Je vous tiendrai informé

  Zilliq

  

  zilliq

  Participant

  Topics: 58

  Replies: 683

  Been thanked: 152 times
  03/27/2016 at 5:14 PM #4467
  Nicolas

  Pourrais-tu stp partager le code de ta stratégie pour bien comprendre ton raisonnement ? Merci.

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20828

  Been thanked: 4739 times
  03/28/2016 at 8:54 AM #4488
  Doctrading

  Bonjour Zilliq

  Je te montre un résultat d’un de mes backtests.

  Même problème : en fait PRT compte le TP et non le SL lorsqu’ils sont touchés sur la même bougie !!!

  Donc le test est faussé et trop beau pour être vrai.

  Il me semble que c’est la peut être la même chose sur ton test, étant donné ta courbe ; cependant ton graphe est en 5 minutes, le mien est en 4 heures.

  Après bien sûr, je en connais pas ton code donc je ne peux pas donner mon avis.

  En modifiant même les paramètres de mon test et en mettant un stop loss à 1 pip seulement, j’obtiens un profit factor délirant à plus de 20 ou quelque chose comme ça…

  Donc le test est faussé, je ne me suis même pas risqué à le lancer en automatique !

  Une prochaine version de ProRealTime devrait pouvoir corriger ce problème.

  Bons trades à tous !

  

  

  Doctrading

  Participant

  Topics: 44

  Replies: 172

  Been thanked: 2 times
  03/28/2016 at 9:25 AM #4491
  zilliq

  Bonjour à tous,

   

  
  @Doctrading

  Oui c’est exactement ca.

  
  @Nicolas

  La stratégie a peu d’intérêt c’était simplement pour bien montrer les erreurs des backtests sur PRT et donc de bien s’en méfier en terme de surévaluation

  // Définition des paramètres du code DEFPARAM CumulateOrders = False // Cumul des positions désactivé ti=time>080000 and time<210000 mm=2 sll=1 tpp=8 // Conditions pour ouvrir une position acheteuse indicator1 = RSI[34](close) indicator2 = ExponentialAverage[mm](RSI[34](close)) c1 = (indicator1 CROSSES OVER indicator2) and (indicator2>indicator2[1]) and ti IF c1 THEN BUY 1 CONTRACT AT MARKET ENDIF // Conditions pour fermer une position acheteuse indicator3 = RSI[34](close) indicator4 = ExponentialAverage[mm](RSI[34](close)) c2 = (indicator3 CROSSES UNDER indicator4) IF c2 THEN SELL AT MARKET ENDIF // Conditions pour ouvrir une position en vente à découvert indicator5 = RSI[34](close) indicator6 = ExponentialAverage[mm](RSI[34](close)) c3 = (indicator5 CROSSES UNDER indicator6) and (indicator6<indicator6[1]) and ti IF c3 THEN SELLSHORT 1 CONTRACT AT MARKET ENDIF // Conditions pour fermer une position en vente à découvert indicator7 = RSI[34](close) indicator8 = ExponentialAverage[mm](RSI[34](close)) c4 = (indicator7 CROSSES OVER indicator8) IF c4 THEN EXITSHORT AT MARKET ENDIF // Stops et objectifs //SET STOP pLOSS 8 pTRAILING 1 SET STOP pTRAILING sll SET TARGET PROFIT tpp

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

  // Définition des paramètres du code DEFPARAM CumulateOrders = False // Cumul des positions désactivé ti=time>080000 and time<210000 mm=2 sll=1 tpp=8 // Conditions pour ouvrir une position acheteuse indicator1 = RSI[34](close) indicator2 = ExponentialAverage[mm](RSI[34](close)) c1 = (indicator1 CROSSES OVER indicator2) and (indicator2>indicator2[1]) and ti   IF c1 THEN BUY 1 CONTRACT AT MARKET ENDIF   // Conditions pour fermer une position acheteuse indicator3 = RSI[34](close) indicator4 = ExponentialAverage[mm](RSI[34](close)) c2 = (indicator3 CROSSES UNDER indicator4)   IF c2 THEN SELL  AT MARKET ENDIF   // Conditions pour ouvrir une position en vente à découvert indicator5 = RSI[34](close) indicator6 = ExponentialAverage[mm](RSI[34](close)) c3 = (indicator5 CROSSES UNDER indicator6) and (indicator6<indicator6[1]) and ti   IF c3 THEN SELLSHORT 1 CONTRACT AT MARKET ENDIF   // Conditions pour fermer une position en vente à découvert indicator7 = RSI[34](close) indicator8 = ExponentialAverage[mm](RSI[34](close)) c4 = (indicator7 CROSSES OVER indicator8)   IF c4 THEN EXITSHORT  AT MARKET ENDIF   // Stops et objectifs //SET STOP pLOSS 8 pTRAILING 1 SET STOP pTRAILING sll SET TARGET PROFIT tpp

  Et sinon, pour le fun, la “stratégie” rien que ce matin en trading auto sur compte démo : Le massacre  !

  11 pertes 0 gagnant ! Alros que l’on était à plus de 85 % de trades gagnants sur le backtest (erroné!)

  385 euros de pertes virtuelles

  Je pense que la démonstration est faite ! Je coupe le trading auto de la démo c’est ridicule. Et encore une fois, en l’état méfier vous des backtests PRT et leurs surévaluation dès lors que vous avez potentiellement ouverture et fermeture sur la même bougie

  A +

  Zilliq

   

   

  

  zilliq

  Participant

  Topics: 58

  Replies: 683

  Been thanked: 152 times
  03/28/2016 at 9:31 AM #4494
  Nicolas

  Les backtests n’étant pas réalisé en tick par tick, les conditions de sorties ne sont testées qu’une seule fois par bar. Plus le timeframe employé est important, meilleur seront donc les résultats, car il se passe un tas de chose durant une barre de 4 heures par exemple. Ce problème est connu et en passe d’être résolu. Pour garder une rapidité de test et être plus “accurate” avec les informations du prix, le principe serait de tester toutes les barres des timeframes inférieures pour tester si les conditions de sorties ont été rencontré, par exemple :

  Backtest de la barre X en H4 -> test des conditions de sorties des 2 barres en H2 -> test des conditions de sorties des 4 barres en H1 -> test des conditions de sorties des 4 barres en M30 -> test réussi -> passage à la barre Y en H4 -> ainsi de suite ..

  A quoi sont dues les pertes indiquées par ton rapport Doctrading ?

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20828

  Been thanked: 4739 times
  03/28/2016 at 9:50 AM #4496
  zilliq

  Salut Nicolas,

  C’est ce que je disais précédemment : Tester les UT inférieures du backtest 😉

  On est donc du même avis, espérons qu’il en soit de même pour les programmeurs PRt

  Passe une bonne journée

  Zilliq

  

  zilliq

  Participant

  Topics: 58

  Replies: 683

  Been thanked: 152 times
  03/28/2016 at 10:05 AM #4497
  Doctrading

  Effectivement, ça fait mal… mais on s’y attendait.
  Bonne journée

  

  Doctrading

  Participant

  Topics: 44

  Replies: 172

  Been thanked: 2 times
  03/28/2016 at 12:34 PM #4510
  Nicolas

  @doctrading Pour les backtests, les takeprofit sont testés prioritairement, avant les stoploss.

  
  @zilliq Ce que j’ai décrit est déjà en développement et s’appelle la “levée de doutes”, qui plus est ce développement interne chez PRT s’accompagne du multi-timeframe. Avant de déployer un correctif ou plutôt une amélioration dans le cas présent de la plateforme, à presque 500.000 clients, il faut s’assurer que celui-ci soit parfaitement fonctionnel, rétro-compatible avec toutes les anciennes versions de code qu’utilisent ces milliers de clients et cela avec les plus de 200.000 instruments tradables automatiquement avec ProRealTime, que PRT est utilisé par beaucoup de courtiers européens (dont certains dont vous n’avez jamais entendu parlé, situé en dehors de nos frontières) et que ceux-ci n’assurent pas eux-mêmes leurs propres supports techniques… Donc avant que les ingénieurs de PRT ne release une version ou une amélioration, elle est testé et éprouvé pour qu’il n’y ai aucun doute possible sur sa performance et sa stabilité !

  Pour mémoire, on parle ici d’une plateforme de trading professionnel délivré par une société Française (cocorico!), qui est courtier agréé AMF (pardon Monsieur!) et accessible gratuitement (avec flux payants) à n’importe quelle personne désireuse de faire du trading ou simplement utiliser ses nombreuses fonctionnalités en “offline” pour faire de l’analyse technique, des calculs statistiques ou tout ce qui peut être possible de faire grâce à ses fonctionnalités de programmation.

  Zilliq, tu peux être rassuré sur le fait que chaque demande que tu fais, d’autres y ont déjà pensé ou réclamé. Mais pour les mêmes raisons techniques que je viens de citer, il y a un processus long et INDISPENSABLE à respecter.

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20828

  Been thanked: 4739 times
  03/28/2016 at 4:48 PM #4522
  zilliq

  Merci Nicolas, je me doute bien, mais tu sais toutes ces améliorations je leur en ai parlé (je suis utilisateur depuis des années et des années, j’ai oublié mon premier abonnement), je ne sais combien de fois, depuis des années, alors bon c’est un rien rageant. Je leur en ai aussi parlé lors des salons AT. Et dans les faits et bien on attend toujours certaines améliorations importantes

  Et je ne te parle pas des remontées de bug que j’ai faite en direct avec eux et qui ne sont toujours pas corrigé après des années d’insistance

  Allez un petit pour le plaisir :

  créez un indicateur simple, avec t comme variable de MM type

  ind=average[10,t](close)

  return ind

  Essayez maintenant de sélectionner moyenne de Hull 😉

  Et oui je sais c’est un poil irritant

  A bientôt

  Zilliq

  

  zilliq

  Participant

  Topics: 58

  Replies: 683

  Been thanked: 152 times
  04/09/2020 at 9:12 PM #125493
  deleted2104

  salut zilig

  jai testé ta strategie euro usd sur 100000 bougies en 1 mn 5 mn 30 mn 12h 24 h la courbe des gains est effectivement super linéaire voir douteuse pour refléter la réalité en trade direct auto pour 10KE ….

  mais bon est ce que avec la V 10.3 crois tu que les erreurs ont été corrigés par PRT et sur la V11 à venir ?

  merci pour ta future réponse

  

  deleted2104

  Member

  Topics: 0

  Replies: 20

  Been thanked: 0 times
  04/10/2020 at 8:39 AM #125528
  Nicolas

  Ce phénomène n’existe plus depuis bien longtemps maintenant (depuis Septembre 2016). La version 10.3 a intégré les backtests en “tick par tick” (il faut cocher la case lors d’un backtest) et tous les niveaux de prix connus à l’intérieure d’une bougie sont bien testés ! Donc pas d’inquiétude pour vos backtests vis à vis de cette ancienne lacune 😉

  Voir cette vidéo: Backtest en tick par tick avec ProRealTime

   

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20828

  Been thanked: 4739 times
  04/10/2020 at 3:07 PM #125585
  deleted2104

  mais le problème c’est que le code de zilig ne prend pas en compte le tick par tick

  donc quoi modifier dans le code pour le tick par tick ?

  merci

  

  deleted2104

  Member

  Topics: 0

  Replies: 20

  Been thanked: 0 times
  04/10/2020 at 3:14 PM #125590
  Nicolas

  Rien, il faut cocher la case avant de lancer le backtest,  voir vidéo.

  

  Nicolas

  Keymaster

  Topics: 81

  Replies: 20828

  Been thanked: 4739 times
  04/10/2020 at 3:25 PM #125591
  deleted2104

  merci

  

  deleted2104

  Member

  Topics: 0

  Replies: 20

  Been thanked: 0 times
• Author
  Posts