L'equity de la mort

TickTack merci pour ce retour

En 2018 tu as développé le goût de performances supérieures à celles qui autrefois te satisfaisaient (5%), ce qui est déjà je crois très positif.
Cette année tu devrais être en mesure de passer de façon significative dans le vert.

Il me semble que si tes essais "forward" (donc en réel) n'ont pas été concluants, ce n'est que la preuve de l'incomplétude de tes procédures de test.
Si tes tests n'ont pas révélé que l'algo ne fonctionnerait pas, c'est qu'ils ne couvraient pas un champ de configurations assez vaste ou alors que tes datas sont pourries (ou les deux).
Mais je pencherais plutôt nettement pour la première option.

En fait tu as à la fois raison et tord, c'est bien la procédure de test dans son ensemble qui est incomplète/bancale, mais ça n'est pas lié au champ de configurations car j'ai backtesté depuis 2007 (donc en incluant le dernier gros krach).
J'ai fait principalement 2 erreurs:
1) le grand classique: sur optimisation de certains paramètres
2) par manque de temps de codage et/ou de puissance de calcul je n'ai pas pu faire des backtests "par tranches de temps" : en gros j'ai calculé des paramètres qui passaient à peu près bien chaque année sur tout l'échantillon au lieu de prendre des paramètres sur les N premiers mois , effectuer un backtest sur les P mois suivants, puis avancer de proche en proche en refaisant les backtests à chaque fois.
Je l'ai fait récemment sur une seule stratégie et effectivement les résultats n'ont rien à voir , ils sont bien plus réalistes (et donc bien plus médiocres).

ça n'est pas lié au champ de configurations car j'ai backtesté depuis 2007

Attention, c'est une totale illusion !!!

Et 1) est la conséquence de 2).
J'ai indiqué dans l'un de mes messages que je testais dorénavant en lançant le programme à des centaines de points de départ différents, de façon aléatoire. c'est l'une des choses découvertes sur le tas, à force de bosser sur le sujet.

En effet, le programme se comportera le plus souvent différemment en fonction des conditions initiales.
L'exemple le plus évident est celui d'un programme qui limite le nombre d'ordres passés à un cumul max de N, ou le levier.

Il est donc très incomplet de se contenter d'un test sur une longue période, même si c'est 10 ans.

Je vais poster un message dans ma file pour donner un exemple de ce que je réalise, si cela peut aider pour tes propres réflexions.

Oui je lirai avec attention ton message , peut être aurais je une révélation

Je teste actuellement en démo mon nouveau robot et je constate que les trades longs sont toujours ouverts en ma défaveur par rapport au prix théorique du backtest (qui est l'open de la barre 1mn suivante).
En short en moyenne c'est en ma défaveur mais il y a malgré tout certains trades ouverts à un prix meilleur que le prix théorique.
Le problème est que le décalage va de 1 à 9 points sur le dax, ça commence à faire beaucoup même si il y a un décalage de quelques secondes entre l'ouverture théorique et l'ouverture réelle du trade.
Ce qui me gêne ça n'est pas l'amplitude de l'écart mais le fait qu'en long ça soit toujours dans le mauvais sens (j'achète toujours plus cher que la théorie) ... je ne vois pas d'explication logique.
L'échantillon est encore faible (20/25 trades longs) mais statistiquement j'aurai déjà été très malchanceux si c'est juste le hasard.

Pour ma part, j'ai programmé mes backtests pour qu'un trade soit systématiquement pris avec un prix réel aléatoirement défavorable par rapport au prix théorique. Je pense que la solidité d'une stratégie ne doit pas être conditionnée par l'entrée sur un prix exact.

Bon je ne comparais pas les bons chiffres, en comparant avec l'historique ig l'écart est moins important (écart moyen en ma défaveur inférieur à 2 points) et j'ai pu trouver des trades longs avec un prix d'entrée en ma faveur (c'est rare mais c'est arrivé).

Mais je vais devoir en tenir compte dans les backtests, j'avais mis un très léger slippage mais ça n'était pas suffisant.

@Takapoto
Oui l'idée est intéressante.
J'imagine que tu utilises un générateur aléatoire et qu'il est symétrique, par exemple un nombre réel entre -1 et +1.
Ensuite tu mets à l'échelle et tu transposes cela sur le prix en cours.
Tu obtiens alors un prix de transaction à mener qui est aléatoire et centré sur le prix réel.
C'est là où, dans une telle hypothèse, vient une interrogation. Un prix aléatoire centré sur le prix réel reviendrait en moyenne à prendre le prix réel. Si tel était le cas, alors la variabilité des scénarios de test serait faible.
Mais je vois que tu prends un prix systématiquement défavorable. Si l'on imagine qu'il s'agit de quelques points, avec le générateur aléatoire cela reviendra également à prendre un prix qui sera en moyenne défavorable de x pips, x étant déterminé précisément par la façon de paramétrer le générateur. En d'autres termes cela revient à prélever une commission supplémentaire de y% ou également réaliser un offset du 0 rendement et donc se dire que le résultat doit excéder une valeur de y%. Donc in fine, si le générateur est utilisé de la façon que j'imagine, je ne capte finalement pas l'apport pour mesurer la robustesse de l'algo.
Peux tu nous éclairer sur ce sujet ?

Une autre piste pour ceux comme moi qui veulent un backtest réaliste mais qui renvoie toujours le même résultat (pour éviter de lancer X fois le backtest) : au lieu d'utiliser un mécanisme aléatoire qui en moyenne va être défavorable de P points, je décale directement le point d'entrée de P points à chaque fois (et le point de sortie si c'est un close AT market).
On perd la "fourchette" des equity possibles mais on obtient une equity dans le milieu de la fourchette, moi ça me suffit.

Voici comment je procède pour ma part:

Prémisse: si un algo est structurellement gagnant, alors il devrait par définition toujours l'être, quelque soit l'espace temporel exploré.
Que je le lance le 1er février, ou le 17 mars ou le 21 juin etc d'une année n, il est en mesure de toujours sortir un résultat positif au bout d'un temps t (Plus t est court et meilleure est la perspective).
Il doit également être en mesure d'enchaîner des combinaisons variables de configurations (d'amplitude et fréquence également variables), telles que évolution sinusoidale, rampe, échelon, quasi droite etc
Cette dernière contrainte est en lien direct avec la notion de max DD . En effet, un algo sera plus efficace dans l'une ou l'autre de ces configurations et c'est l'enchaînement de configurations moins favorables qui créera le DD.
Pour moi, il me faut donc un système de test qui multiplie ces enchaînements, on pourrait faire une analogie partielle avec un système de Monte Carlo.
Comme un algo évolue toujours avec des contraintes de volumes (nombre d'ordres, volume engagé max), en prenant le cas le plus simple on peut dire qu'à un temps t1 dans une configuration C1 un ordre O1 est pris et qu'il peut être en mesure d'empêcher de prendre à t2,C2 un ordre O2. OK?
C'est tout à fait similaire à ce que l'on voit sur les vidéos présentant les systèmes chaotiques (par exemple billard, cascades de Feigenbaum etc)
Ainsi les conditions initiales, donc le moment où le test est lancé peuvent avoir de l'importance sur le résultat (cela dépendra bien sûr des algos). Pas tellement sur le résultat sur une durée longue mais sur l'identification de Max DDs. Notre ennemi commun

Maintenant dans la pratique, il y a une façon très simple de mettre en oeuvre cela.
Il suffit donc de relancer l'algo à des dates aléatoires.
Pour se faire on peut tout simplement mettre en place un module qui coupe toutes les positions dès que l'equity a atteint une valeur X (X% de l'equity ou une valeur fixe de N euros). En faisant varier cette valeur lors de campagnes de tests on obtiendra des centaines de redémarrage de l'algo, à chaque fois différents pour chaque valeur de X). X doit être suffisamment grand pour valider que l'algo est bien profitable, mais pas trop non plus afin d'initier un nombre suffisant de redémarrage.

Cette façon de procéder est moins consommatrice de temps que de relancer manuellement et a l'avantage d'avoir un caractère aléatoire.
Sur ma file du robot imparfait, je vous montrerai pour l'illustrer les résultats d'une campagne en cours (dès que j'aurai suffisamment avancé pour montrer un set de résultats variés) et la façon dont je les lis.

Cela concerne surtout les systèmes ou l'on laisse les trades ouverts plusieurs jours.
Si on ferme tous les trades tous les soirs par exemple la date de démarrage a très peu d'impact.

C'est vrai
Sauf si le trading intraday est très intensif, car on peut voir une année comme une succession de jours ou bien une journée comme une succession de minutes, la face fractale des marchés (qui ouvre potentiellement bien des opportunités)

La réflexion d'Euraed est également vraie dans des systèmes qui ne passent pas beaucoup de trades par jour et qui sont fermés en fin de journée.
Si une seule position à la fois est autorisée, elle peut empêcher une prise de position en sens inverse qui aurait été plus profitable (ou moins).
Pour valider ce genre de stratégie, je fais varier la période pendant laquelle le trading est autorisé.

En général j'autorise simultanément une position à l'achat et une à la vente pour chaque sous système, en apparence ça parait totalement inutile mais quand on combine plusieurs sous systèmes ça lisse parfois les performances, du moins j'ai pu le constater empiriquement.
Mais effectivement quand une position dans un sens est ouverte, si on limite à 1 (ou N) ça fait rater d'autres ouvertures potentielles dans le même sens, du coup les heures ou le trading est autorisé ont un impact fort.
C'est d'ailleurs un point faible de mes algos, je filtre souvent les horaires les plus défavorables du coup ça optimise un peu trop car selon les périodes les horaires favorables varient ...
Mais pour certains systèmes on voit quand même une certaine constance sur les années, certaines heures sont nettement perdantes et d'autres nettement gagnantes.
Un exemple tout bête est que bien souvent plus on laisse de temps aux trades intraday pour respirer , moins la performance est mauvaise, donc souvent les horaires favorables pour ouvrir les trades sont tout bêtement le début de journée (si le TP est assez éloigné, pour du scalping ça n'a aucun intérêt)

Tu connais ma position sur le sujet de la sélection des horaires par l'algo, parce qu'ils seraient supposés plus favorables: pour moi c'est un leurre.
Comme tu le soulignes il y aura toujours une fluctuation de ces horaires.
Il peut à tout moment se passer un truc inattendu, sélectionner des horaires revient à vouloir sélectionner des configurations favorables pour l'algo. Pour moi c'est une chimère, un piège. Par chance, tu vas finir par avoir l'illusion que cela fonctionne bien, jusqu'au moment où... MaxDD.

Tes perfs sont lissées car tu as plusieurs logiques d'entrée en position. Cela te crée donc un nuage de points short/long dans un environnement stochastique. Dans ce nuage, le signal va se balader de façon quelconque et sortir un résultat moyenné. C'est cela qui lisse.
Il faut dans ce cas avoir un avantage statistique régulier, ce qui n'est pas évident du tout.
D'autant plus qu'un tweet ou équivalent peut tomber à n'importe quelle seconde

Félicitations TickTack, déjà tu es vert sur l'année, c'est une bonne chose. Pour le reste, je vais prendre le temps de lire vos échanges hein...

Merci BeerisDead , si on peut te donner des idées ça servira au moins à quelqu'un

@Euraed, je suis disons plus mitigé sur le leurre de la sélection horaire, autant sur beaucoup de systèmes tu as raison je constate que c'est un tour de passe passe que l'on fini par payer cher un jour ou l'autre, mais parfois il y a vraiment une certaine stabilité dans le temps du phénomène.
ça peut être du tout simplement à la structure du système: s'il est calibré pour fonctionner par temps calme, il est logique de s'attendre à une dégradation des performances aux heures les plus actives de la journée (qui sont souvent les mêmes), les éviter n'est pas un leurre à mon sens.
Après tu me répondras que si le système est bien conçu il les évitera de lui même sans besoin de filtre horaire.
Mais pour les QI modestes comme le mien , le filtrage horaire est la solution du pauvre (intellectuellement parlant)

Juste un petit retour d'info pour redonner un peu d'espoir à ceux qui tente en vain de programmer un robot de trading qui se comporte exactement pareil en backtest (théorie) et sur le compte de trading (pratique).
Depuis l'an passé je n'avais réussi au mieux qu'à obtenir un comportement "cohérent" (en terme de gain/pertes) par rapport à la théorie.

Depuis la prise en compte du slippage constaté empiriquement sur le compte démo ig , ces 3 dernières journées de trading le robot a terminé avec un écart de 1€ seulement par rapport à la théorie ... c'est quasiment de l'ordre du miraculeux , je vais devoir retourner faire un tour à Lourdes

Un petit résultat contre intuitif de plus ... voyant mon robot ouvrir souvent plusieurs trades dans le même sens a quelques poins près (à cause des divers sous systèmes indépendants) , je me suis cru très malin et j'ai ajouté une règle pour ne pas ouvrir 2 trades dans le même sens à moins de 0,1% par exemple (j'ai testé différentes valeurs, même résultat).
Et bien en fait ça diminue les perfs et ça augmente le plus souvent la MaxDD.... donc on peut en déduire que statistiquement quand le robot accumule des trades dans la même zone , il le fait le plus souvent pour de bonnes raisons.