ProRealTime
Pour partager sur le trading automatique, nos algorithmes, nos backtests

Re: Debug backtest avant passage en prod

par falex » 19 avr. 2024 19:29

Oui faut éviter de caper les pv et laisser filer les mv… c’est vrai aussi en manuel :-)

J’utilise strategyprofit pour sizer les lots.

Marrant comment chacun l’utilise a sa sauce

Re: Debug backtest avant passage en prod

par G'sT » 19 avr. 2024 20:36

Je considère mon algo non pas comme un robot mais comme un "assistant trader". Dit en d'autres termes je n'ai fait qu'automatiser, via un algo, quelques scalps ciblés quotidiens que j'ai pratiqué et que je maitrise en trading manuel. ;)

Re: Debug backtest avant passage en prod

par trappiste73 » 19 avr. 2024 20:36

Même pour sizer les lots, je suis dubitatif. Finalement, ça revient à caper les pv. D’expérience, tout ce qui ressemble à une martingale est à mettre … à la poubelle !
Peut-être, modifier le nombre de lots selon la volatilité ?

Re: Debug backtest avant passage en prod

par falex » 24 avr. 2024 19:21

Grrrr mais que pro-order me saoul : 3 jours de suite ou je doit relancer mon robot.
Il plante je ne sais pas quand (ça c’est vraiment nul de ne pas avoir de remonter d’info) car il lui manque des preloadbars.

J’ai fini pas mettre la valeur au taquet et ça plante toujours .

Mais comment on debug de « machin ».
J’avoue être un peu dubitatif par pro-order pour l’instant.

Vos retour d’expériences sont les bienvenus.

Re: Debug backtest avant passage en prod

par cafeiine2023 » 24 avr. 2024 21:34

Quelques pistes,
Afficher les valeurs des variables, simplifier le code, tester le code simplifié, erreur/pas erreur, recommencer, jusqu'à cibler l'erreur.
A défaut, réinitialiser tes variables chaque jour
Vérifier si il n'y a pas une division par zero, un nombre de lots incohérent à l'achat (ex:0,333333), un SL qui doit être un limit ( il y a des cas à la c*n).
Passer en backtest le moment où ça a pété en réel.
Tu as fait un test sur une heure exacte 14H00, alors que le code est exécuté sans certitude d'être exécuté à 14h00 mais 14h01, ou 14H00:01s
Partager un morceau de ton code, pour cibler d'où pourrait venir l'erreur (sans certitude d'avoir une bonne réponse)
Les tableaux sont limités à 65000 de mémoire.

Tu peux regarder cette page, elle regorge de subtilité sur la mise en oeuvre d'un pro-order.
https://trading.prorealtime.com/en/automatic-trading-conditions

Re: Debug backtest avant passage en prod

par falex » 24 avr. 2024 21:50

Super merci pour les pistes.

Le message d’erreur est que le code n’avait pas assez de barre pour calculer l’indicateur (mfi(14). J’ai rajouté le preloadbars …

Je pense que ce doit être l’arrondi du nombre de lots.

On peut continuer à grapher une fois passer en pro-order ?

Je peux vous partager tout le code si je bloque complètement. C’est plus un galop d’essai qu’un robot qui va passer en prod.

J’essaye déjà de le faire tourner en démo …

Re: Debug backtest avant passage en prod

par cafeiine2023 » 24 avr. 2024 22:12

"On peut continuer à grapher une fois passer en pro-order ?" En le faisant tourner réellement, je crois bien que non. Mais je ne suis pas allé jusqu'à là. :(

Re: Debug backtest avant passage en prod

par trappiste73 » 24 avr. 2024 22:44

Ce message d’erreur peut venir de données manquantes dans le flux mais plus sûrement d’un bug dans ton code, une redondance, une boucle ou autres.

Re: Debug backtest avant passage en prod

par falex » 30 avr. 2024 14:40

J'ai mis
DEFPARAM PreLoadBars = 10000

en premier dans le code (avant les autres DEFPARAM) et augmenté à 10000 (alors qu'en théorie j'avais besoin que de 14/15 bougies), et cette fois-ci j'ai eu un nouvel arret pour "Taille d'ordre trop grande".

Alors je vais revenir à une taille de 1 et je vais voir si ça passe.

Re: Debug backtest avant passage en prod

par falex » 30 avr. 2024 14:45

Les fonctions GRAPH et GRAPHONPRICE ne sont pas utilisable en Pro-Order, uniquement en Backtesting.

Re: Debug backtest avant passage en prod

par falex » 30 avr. 2024 15:27

Pour évaluer le passage d'ordre j'ai fait un robot de debug.

L'erreur de mon premier code était un problème de décimale dans le nombre de lot envoyé.
--> Corrigé.

Mais alors là je suis sacrément surpris de la façon dont sont executés les codes.

Dans l'ordre du code, une fois tous les feux vert allumés le code balance un BUY pos SHARES AT MARKET

Plus loin et vers la fin du code j'ai ça :

Code : #

if COUNTOFLONGSHARES > 0 then
   set target pPROFIT tp
   set stop pLOSS sl
elsif COUNTOFSHORTSHARES > 0 then
   //set target pPROFIT tp
else
   set target pPROFIT 0
endif
ça veut qu'entre l'execution du code et l'entrée en position il y a un délais. Or le code n'est executé qu'à la cloture de la Bougie.

En paliatif j'ai rajouté les lignes

Code : #

   set target pPROFIT tp
   set stop pLOSS sl
Juste après ma ligne BUY pos SHARES AT MARKET
mais seule le SL est positioné et comme plus haut à l'exectuion suivante le code rajoute le TP.

Il y a un moyen de positionner les TP/SL dès que l'ordre a été servi ? (genre un tick-by-tick pour l'execution du code).

Re: Debug backtest avant passage en prod

par falex » 30 avr. 2024 15:36

Ah non en relisant mon code c'est peut-être mon Else du premier if qui a mis le TP à 0.

Re: Debug backtest avant passage en prod

par falex » 30 avr. 2024 15:44

Auto-réponse :
Si je met les set STOP et TARGET tout de suite après le BUY alors le systeme ouvre un ordre met les bonnes valeurs de TP+SL.

Pas besoin de mes IF COUNTOFLONGSHARE ... (sauf si on veut faire un STOP/TARGET sur pru mais là c'est une autre histoire).

Ouf ça me rassure car je me voyais mal gérer un algo qui n'aurais pas été capable d'ouvrir une position et de mettre le SL/TP dans la foulée.

Re: Debug backtest avant passage en prod

par trappiste73 » 30 avr. 2024 15:50

Oui ça marche sans problème en cfd à risque limité. Sur les futures … hum.

Re: Debug backtest avant passage en prod

par cafeiine2023 » 30 avr. 2024 17:46

L'intérêt de ces fonctions est de savoir si tu es en position. La bonne pratique est de le faire en début de code, ainsi tu sais si tu es actuellement en position ou non.

Ces fonctions n'ont pas d'intérêt à être utilisés avec un ordre buy au sein de la même exécution.

Re: Debug backtest avant passage en prod

par ChristelleP » 03 mai 2024 01:03

up-1.jpg
up-1.jpg (10.9 Kio) Vu 9 fois

Re: Debug backtest avant passage en prod

par falex » 03 mai 2024 22:21

Bon un truc que je découvre et que j’avais lu mais pas testé :

Si on fait du pro order sur ig, si on a le malheur de passer un trade sur ce compte bam bam bam ça arrête toute la mécanique pro-order.

Sur ig on peut ouvrir deux comptes cfd à risque limité … donc vous l’aurez vite compris il faut en dédier un au manuel et le second à pro-order.

Sujets similaires
Help ! appel a debug ! pyramidage avec sortie flat
Fichier(s) joint(s) par ladefense92800 » 03 juin 2015 23:30 (25 Réponses)
serie person of interest cree J Nolan prod jj abrams
par Lysan » 11 févr. 2017 09:55 (3 Réponses)
Prt BackTest Fiabilité; inclure premier passage
par Deejay87 » 23 déc. 2018 18:41 (1 Réponses)
Backtest cohérence passage d'ordre
Fichier(s) joint(s) par Zogzog » 02 avr. 2020 14:15 (0 Réponses)
Pro Backtest
par VinceMan » 17 juil. 2012 14:30 (4 Réponses)
backtest PRT?
Fichier(s) joint(s) par Djobydjoba » 05 avr. 2013 09:26 (11 Réponses)
Backtest et Excel
par Greg31600 » 18 avr. 2013 01:26 (4 Réponses)
code PRT > RSBoll/Seuil backtest
par newworld » 16 juin 2013 17:57 (4 Réponses)
ProRealTime backtest : appel à témoin
par falex » 17 août 2013 16:19 (1 Réponses)
Backtest Prorealtime
par Fredo » 04 oct. 2013 16:34 (5 Réponses)