Debug backtest avant passage en prod

[falex]

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

[G'sT]

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.

[trappiste73]

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é ?

[falex]

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.

[cafeiine2023]

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

[falex]

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 …

[cafeiine2023]

"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à.

[trappiste73]

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.

[falex]

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.

[falex]

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

[falex]

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).

[falex]

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

[falex]

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.

[trappiste73]

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

[cafeiine2023]

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.

[ChristelleP]

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

[falex]

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.

[trappiste73]

Ça me paraît louche : je le fais depuis toujours par prorealtime chez Ig sans aucun problème. Il y’a peut-être une case à cocher pour le cumul des ordres ?

[falex]

Tester que sur le compte démo

Je verrais sur un de mes réels
-
Tu trades le même epic ?

[trappiste73]

Même ut sans problème.