Debug backtest avant passage en prod

Bonjour falex et vous autres adeptes des algos.
Je connais assez peu le langage prt, habitué de longue date au codage MQL4 et depuis quelques temps MQL5.
Une petite incohérence, il me semble dans ton code, ou alors j’interprète mal la gestions des barres sur prt:

once duree = 15
...
//coupe si trade dure plus de bar (200minutes en UT2)
if OnMarket and ((barindex - tradeindex) > duree) then
sell evalpos contracts AT market

Il me semble que d'après ce code, ça coupe à si le trade dure plus de 15 * 2 = 30 minutes, non ?

Oui c'est bien ça.
La variable "duree" était une variable d'optimisation et la meilleur valeur (en terme de compromis entre coupé trop tôt et trop tard) était 15 dans ce schéma là.

'once' c'et un mot clef pour dire à prt que la varaible est unique et sans historiqe (sinon par défaut ce sont des tableaux que l'on peut indexer par toto_varaible[index].
barindex c'est une variable systeme de prt pour avoir le numéro de de la barre en cours.
et tradeindex c'est le numéro de la barre "IN".

Quelle incohérence vois-tu dans le code ?

Et bien, d'après le commentaire du code, tu dis couper si le trade dure plus de 200 minutes alors que dans le code, c'est 30 minutes.
Merci pour la signification de "once". Je ne connaissais pas.
Sinon, pour les barres, ça semble être le même principe que pour MT4/MT5 avec je suppose, la barre 1 = barre précédente, barre 2, celle juste avant la barre 1 (ordre inverse de l'ordre chronologique)

Ah ok , ne tiens pas compte de la valeur dans le commentaire je ne l’ai pas mis à jour.

prt met à 1 la barre la plus anciennes et incrémente.

Ça reviens au même

Bonjour à tous,

Je viens un peu tard (3 semaines après le message de Falex « 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. »…..je te confirme Falex (comme le dit trappiste73) qu’il n’y a pas de problème pour passer un ordre manuel en plus de proorder, sur la même ut…je le fait à plusieurs reprises (avec TP présaisi ) et aucun problème.
Après si tu fermes ton ordre manuel il faut faire attention de ne pas te tromper de ticket (proorder) sinon dans ce cas là ça te met effectivement proorder en carafe.

Par contre j’ai eu un cas où effectivement proorder bug : quand proorder lance un achat (ou vente) et que toi derrière tu changes le TP ou le SL ça te bug proorder qui s’arrete.
Ca m’est déjà arrivé : proorder tourne normalement, lance un ordre, et à distance sur mon telephone je modifiie le TP…..boum prooder bug et stop (je crois comprendre de cette experience que toute modification manuelle de l’ordre lancé par proorder entraine un bug)
Finalement ce bug je l’utilise comme une force /astuce : si je veux arreter proorder à distance avec comme seul outil un tel…..je modifie le TP sur une position ouverte par proorder et ça stop la machine.

Pour répondre au message de XAVIER du 21 mai « En revanche déçu de voir que ça n'est pas possible en proorder, j'ai justement un decalage d'entré et sortie entre backtest et reel... »
Si on parle de la même chose, il s’agit de la différence entre temps fixe et temps variable. Dans le backtest l’achat (ou la vente) se fait au cours d’ouverture de la Bougie (à T0) alors qu’en réel via prooroder l’achat (vente) se fait à T0 + X dixième de secondes donc jamais au cours d’ouverture de T0 (sauf quelque cas où le cours ne bougerait pas dans les dixième de secondes).
J’avais aussi constaté cette différence. Dans la pratique quand je compare mes points d’entrées avec le cours d’ouverture de la Bougie j’ai toujours moins d’1 point de différence (exceptionnellement ce matin j’ai vu un décalage exceptionnel de 2 points que je ne comprends pas).
La parade pour contourner ce décalage de « moins d’1 point » que j’ai trouvé c’est de baisser mon TP backtesté d’1 point pour le lancement de l’algo. De manière plus concrète mon algo programmé pour prendre les trades que je prends en manuel de manière ciblée sur des récurrences (TP 3), après avoir backtesté avec le TP3 pour valider mon programme, lorsque que j’ai passé l’algo en réel j’ai changé le TP à 2 points.

1 points de moins sur 3 ça fait quand même 33% en moins dans ton portif.

Effectivement il y a forcément une latence entre prt qui calcule le code et qui shoot l'ordre de rentrer et la backtest qui met cet latence à 0ms.

Si tout va bien, début du mois prochain je me lance un peu en réel, histoire de me confronter à tout ces bugs.

Faut bien se jeter dans le grand bain un jour ou l'autre

Oui vu comme ça 33 % ça peut paraitre beaucoup mais l'objectif reste le zero faute ou tout au moins de "TENDRE" vers le 100 % de réussite autant que faire se peut.
Il faut parfois faire des compromis pour éviter la "suroptimisation" et trouver le bon équilibre.
Je préfère sacrifier 33 % de mes gains en échange de trades gagnants

Je te souhaite de la réussite dans ton lancement en réel algo....tu verras au début on est jamais complètement tranquille d'esprit mais comme tu dis faut se lancer et quand l'algo est lancé et après si ça marche ça roule tout seul (sans y oublier les remises en cause de temps à autre).
Bon courage.

En repensant à tes messages, G'sT, est-ce qu'une solution serait d'augmenter le spread, lors des backtest pour se rapprocher de la réalité ?
Exemple nasdaq en horaire cash sur ig spread 1, mais en suivant ton exemple tu le mets à 1,33 ou 1,5.

Qu'en penses-tu ?

Merci Guest
Je n'ai pas reproduit le probleme, cet algo n'a pas repris de trade depuis et je l'ai plus ou moins remplacé par un en 10seconde.

Tranquilité d'esprit : difficile de se dire qu'il n'y a plus rien à faire (autre que surveiller), j'aime l'idée mais je me dis que c'est trop facile. Et oui, même en auto le coté psy du trading est là

Falex,
Pas tout à fait ta question mais perso j'ai un algo qui tourne de 8H à 22H sur DAX, j'ai backtesté avec 3pts de spread (tout le temps). Donc mes réulstats backtests sont moins bien qu'en réel

Je trouve qu’il est prudent, voir indispensable, de prendre au moins 1 point de ‘marge’ que ce soit sur le spread ou le tp s’il est fixe.

Ok les amis je retourne à mes backtests avec +1 sur le spread.

plus haut , on évoquait la suroptimisation . Un bel exemple avec toute une partie de code :

timeframe (10 second)
rem avant 190 10
if (time>100000 and time<110000) or (time>123500 and time<133000) or (dayofweek=2 and ((time>110000 and time<144000)or time>165000)) or (dayofweek=3 and ((time>121500 and time<131500) or haut3=0)) or (time>160000 and time<161500) or (dayofweek=1 and time<100000) or (dayofweek=4 and ((haut10=0 or haut3=0) or (time>093000 and time<100000))) or (dayofweek=1 and (haut3=0 or close>(highest[40][1]-10))) or (dayofweek=2 and haut3=0 and time<110000) or (dayofweek=4 and (close>(highest[60][1]-10))) or (dayofweek=5 and close>(highest[60][1]-10)) or (dayofweek=4 and time>153000 and time<170000) or (dayofweek=5 and time<110000) or (haut10=0 and close>(highest[40][1]-15)) or (dayofweek=5 and (haut30s=0 or haut3=0) and time<120000)or (dayofweek=1 and ((haut10=0) or close>(highest[40][1]-15))) or (dayofweek=3 and time>143000 and haut30s=0) or ((dayofweek=4 or dayofweek=1) and haut5m=0) or ((dayofweek=4) and (close>(highest[50][1]-15)) and time<153000) or (dayofweek=5 and time>152900 and time<154000) or (dayofweek=5 and haut30s=0 and time>140000 and time<153500) or ((dayofweek=2 or dayofweek=3) and (time>150000 and time<153500)) or (dayofweek=2 and time>152900 and time<154500)or (dayofweek=3 and time>110000 and time<113500) or (time>=161500 and time<163000) or (dayofweek=5 and haut30s=0) then
stopa=1
else
stopa=0
endif
rem
if (time>=100000 and time<103000) or (time>130500 and time<140000) or (dayofweek=5 and (time>103000 and time<121000)) or (dayofweek=4 and close<(lowest[45][1]+12)) or (dayofweek=2 and (haut3=1 or haut30s=1)) or (dayofweek=4 and haut3=1) or ((dayofweek=5 or dayofweek=3) and (close<(lowest[150][1]+19) or (close<(lowest[60][1]+25)))) or (time>162500 and time<170000) or (dayofweek=1 and (close<(lowest[40][1]+10) or (time>=091000 and time<104500))) or (time>093000 and time<100000) or (dayofweek=2 and time>120000 and time<130000) or (dayofweek=4 and ((time>111500 and time<130000) or (time>144500 and time<150000))) or (dayofweek=1 and haut3=1) or ((dayofweek=4 or dayofweek=5) and ((close<(lowest[150][1]+21)) or (time>151000 and time<153000))) or (dayofweek=4 and time<091000) or (dayofweek=4 and (close<(lowest[50][1]+15))) or (dayofweek=2 and ((time>110000 and time<111500) or (time>142500 and time<150000))) or (dayofweek=1 and time>133000 and time<143000) or (dayofweek=2 and time>161000 and time<163000) or (close<lowest[90][1]+10) or (dayofweek=2 and time>150000 and time<153000) or (dayofweek=1 and ((haut10=1) or (time>120000 and time<130000 and close<(lowest[40][1]+15))))

conclusion : faut pas abuser des bonnes choses !
L'algo peu performant à sa création est devenu perdant avec 5 trades en 2 jours (on est sur du UT10")
ps : je vous rassure : c'est pas de moi !

Kelly
En effet.


Pour ton code utilise :

Capture d'écran 2024-05-28 172340.png (7.48 Kio) Vu 868 fois

dans l'editeur de message au lieu de la citation

ça donne ça :

Code : #

timeframe (10 second)
rem avant 190 10
if (time>100000 and time<110000) or (time>123500 and time<133000) or (dayofweek=2 and ((time>110000 and time<144000)or time>165000)) or (dayofweek=3 and ((time>121500 and time<131500) or haut3=0)) or (time>160000 and time<161500) or (dayofweek=1 and time<100000) or (dayofweek=4 and ((haut10=0 or haut3=0) or (time>093000 and time<100000))) or (dayofweek=1 and (haut3=0 or close>(highest[40][1]-10))) or (dayofweek=2 and haut3=0 and time<110000) or (dayofweek=4 and (close>(highest[60][1]-10))) or (dayofweek=5 and close>(highest[60][1]-10)) or (dayofweek=4 and time>153000 and time<170000) or (dayofweek=5 and time<110000) or (haut10=0 and close>(highest[40][1]-15)) or (dayofweek=5 and (haut30s=0 or haut3=0) and time<120000)or (dayofweek=1 and ((haut10=0) or close>(highest[40][1]-15))) or (dayofweek=3 and time>143000 and haut30s=0) or ((dayofweek=4 or dayofweek=1) and haut5m=0) or ((dayofweek=4) and (close>(highest[50][1]-15)) and time<153000) or (dayofweek=5 and time>152900 and time<154000) or (dayofweek=5 and haut30s=0 and time>140000 and time<153500) or ((dayofweek=2 or dayofweek=3) and (time>150000 and time<153500)) or (dayofweek=2 and time>152900 and time<154500)or (dayofweek=3 and time>110000 and time<113500) or (time>=161500 and time<163000) or (dayofweek=5 and haut30s=0) then
stopa=1
else
stopa=0
endif
rem
if (time>=100000 and time<103000) or (time>130500 and time<140000) or (dayofweek=5 and (time>103000 and time<121000)) or (dayofweek=4 and close<(lowest[45][1]+12)) or (dayofweek=2 and (haut3=1 or haut30s=1)) or (dayofweek=4 and haut3=1) or ((dayofweek=5 or dayofweek=3) and (close<(lowest[150][1]+19) or (close<(lowest[60][1]+25)))) or (time>162500 and time<170000) or (dayofweek=1 and (close<(lowest[40][1]+10) or (time>=091000 and time<104500))) or (time>093000 and time<100000) or (dayofweek=2 and time>120000 and time<130000) or (dayofweek=4 and ((time>111500 and time<130000) or (time>144500 and time<150000))) or (dayofweek=1 and haut3=1) or ((dayofweek=4 or dayofweek=5) and ((close<(lowest[150][1]+21)) or (time>151000 and time<153000))) or (dayofweek=4 and time<091000) or (dayofweek=4 and (close<(lowest[50][1]+15))) or (dayofweek=2 and ((time>110000 and time<111500) or (time>142500 and time<150000))) or (dayofweek=1 and time>133000 and time<143000) or (dayofweek=2 and time>161000 and time<163000) or (close<lowest[90][1]+10) or (dayofweek=2 and time>150000 and time<153000) or (dayofweek=1 and ((haut10=1) or (time>120000 and time<130000 and close<(lowest[40][1]+15))))

OK

Des fois on bute sur les horaires juste par bêtise : j'ai mis plusieurs mois à mettre TP-spread pour m'adapter.

Falex oui effectivement c’est une bonne idée d’augmenter le spread dans le backtest mais je suis du même avis que Trappiste73, à savoir avoir une marge soit à minima d’1 pt.

Après j’ai monté mon algo à l’envers, c’est-à-dire que je n’ai pas cherché un système algo que j’ai optimisé pour gagner de l’argent mais j’ai codifié le trading manuel que je faisais. Un peu comme si tu construisais un robot pour remplacer les gestes d’un ouvrier dans une usine.
Mon algo doit reproduire ce que je fais au quotidien en manuel l’objectif étant de gagner en liberté (=moins de temps derrière l’écran) . Mais ça ne veut pas dire que je ne fais plus du tout de manuel.
Hier j’avais du temps j’ai fait tourné mon algo et j’ai manuellement tradé en même temps

Falex, si tu le souhaites, je t’encourage à lancer ton algo en réel dès que possible si ton backtest est concluant, puis après tu ajustes ton algo dans la réalité en fonction des résultats…..

Essaye de faire via le backtest quelque chose de fiable (et viable qui tient la route), tu lances en réel puis tu mets en marche ton département « recherche et développement » pour apporter les patchs correctifs au réel selon les décalages que tu constateras……

Car au final il y aura surement des décalages par rapport aux backtests. Tiens lors de ma séance de trading d’hier j’ai constaté un autre cas de décalage algo backtesté – algo réel.

Voici l’expérience que j’ai faite hier. J’ai lancé pour la journée mon algo –réel - et en complement j’ai fait fait du trading manuel. Parallelement de ces 2 « phases » de trading j’ai lancé le même algo en version backtest. Et bien figure toi que l’algo « backtesté » n’a pas fait un résultat similaire à celui du même algo en réel. Les 2 résultats étaient positifs mais en version backtestée l’algo avait fait quelques trades de plus (donc résultat algo backtesté >résultat algo réel). Ceci est dû au décalage des cours d’entrée tels qu'on le soulignait précédemment avec Xavier.

@Xavier…tiens donc tu me prends pour un invité maintenant « Guest »

……il n’y a jamais « plus rien à faire »…..bien au contraire une fois l’algo lancé il faut activer les 2 autres départements : le « departement contrôle » et le « departement recherche et développement » parceque le 100 % n’existe pas et il peut parfois etre opportun d’apporter des patchs correctifs et d’autre part ne pas oublier que le marché mute perpetuellement et par consoéquent aucun algo ne peut marcher ad vitam aeternam sans rien y toucher.

Je teste pour voir ta réaction, c'était ça ou Gist
Sinon je ne sais pas prononcer...

Cest vrai qu'il n'y a pas "plus rien à faire", et dans mon cas j'ai encore pas mal d'idée d'algo avant d'attaquer ensuite les screener actions

J'ai un peu de mal à bien cerner comment s'exécute ton code au niveau timing:
//pourcentage taille corps
corps = abs(close-open)
truerange = abs(high-low)
p = 100*corps/truerange
percentagecorps = p > triger

//Facteur de taille de la Bougie
atr = AverageTrueRange[1](close)
ema = ExponentialAverage[7](atr) * multiplicateur
grandebougie = atr > ema

Questions:
Ces calculs sont effectués à chaque tick ou à chaque nouvelle Bougie ?
Si c'est à chaque tick, attention, au premier tick, truerange pourrait être = 0 et donc plantage à cause de la division par 0. D'autre part, dans ce cas, le corps et le truerange de la Bougie sont en constante évolution (à chaque tick). Est-ce bien cette Bougie là que tu veux évaluer ?
Si ce n'est pas à chaque tick, je ne comprends pas ce que représentent les valeurs high low (qui sont celles de la Bougie courante, mais à quel moment ?)

Concernant atr = AverageTrueRange[1](close), sagit-il bien de l'atr de la Bougie précédente ?

@xavier : j aime bien la traduction de Gist en anglais...bien trouvé.
Pour la prononciation de mon pseudo il faut prononcer en phonétique "jésté"

Spoiler:

Par contre au féminin ca s écrit "MaGst"

.

- Falex : quelques unes de mes réflexions si cela peut t apporter quelque chose....

Dans l esprit de ce que nous évoquions ici précédemment j en ai profité pour comparer mes entrées sur les trades du DAX (algo réel) avec les cours d entrées sur le backtest.
Donc pour mes premiers trades de la semaine ca a donné ca :
Trade1 /2/3 …..9/10 = -0,7 /-0,2/-1,2/-0,7/-2,2/-1,2/-0,2/-0,2 /-1,7/-1,2
(au final je me rend compte que sur ces 10 trades là, mes ouvertures se sont faites à mon désavantage par rapport au cours d’ouverture à T0).

Ensuite, j’ai décidé cette semaine de faire de nouvelles expériences.
Pour poser le décor, mon algo fonctionne en réel sur le Dax sur l'ouverture classique du marché (9h-17h30).
J ai backtesté la semaine dernière ce meme algo sur le nasdaq sur la même amplitude journalière et j ai constaté que ce backtest (spread de 2 pts) donnait un meilleur résultat en terme de nombre de trades que mon réel Dax avec un spread de 1,4 pt.
Parceque lundi dernier j étais derrière mon PC j ai décidé de lancer en réel cet algo sur le nasdaq en journée cumulativement avec celui du DAX
Dit en d'autres termes lundi j avais en journée en réel le même algo à la fois sur le DAX et sur le nasdaq. (Je voulais être derrière le pc pour ce double lancement pour pouvoir arrêter la machine si ça se passait mal.....tu connais maintenant mon côté mesuré et prudent....).

Ils ont tourné toute la journée et le résultat :
DAX : 13 trades réussis / 0 perdant
nasdaq : 6 trades réussis 0 perdants

Au final sur cette séance de lundi le résultat sur DAX était supérieur au NAS. Ceci pour une raison simple : j ai programmé mon algo pour ne pas prendre (par instrument) de nouvelle position s’ il est deja en position (if not on market), et ainsi un ordre sur le nasdaq dont le TP n était pas touché a trainé toute une partie de la journée comme un boulet. (Je préfère ne pas prendre de multiples positions pour ne pas être en levier excessif )

La réalité de cette journée unique n’ était pas en réelle adéquation avec le backtest nasdaq comparé au réel DAX.
C’est finalement une illustration de la différence entre le backtest et l aléa de la réalité.

Sur les jours suivants j’ai experimenté en réel d’autres variantes comme mardi des « only short DAX » (pour un day baissier) + FULL NAS ( short+ long) ; mercredi only long DAX+only long NAS ;jeudi only long NAS et aujourd’hui vendredi (journée non terminée) only long dax + only long NAS……….bref j’ai testé en réel plusieurs variantes en fonction de quelques scénarios.
Le bilan sur ces 4 jours (lundi à jeudi) a été de 61 trades gagnants pour 0 perdants

Voilà mon cher Falex si ces expériences peuvent t apporter quelque chose....

L’écart que tu as entre backtest et réel me semble « énorme ».

Est-ce du même ordre de grandeur sur le NDX ?