L’horizon que vous fixez d’abord
Un relevé en direct est le seul test que vous ne pouvez pas fouiller, si bien que sa barre tombe du 4,499 de la leçon 64 à 1,645 et qu’il lui faut 7,48 fois moins de transactions qu’à un backtest de 15 000 cellules pour soutenir la même affirmation. C’est là tout l’argument du test en avant, et il ne tient que si vous fixez le nombre de transactions avant de commencer. Jugez un relevé de 156 transactions une seule fois, à la transaction 156, et un système sans le moindre avantage passe 5,05 pour cent du temps. Jugez le même relevé après chaque transaction à partir de la vingtième, en vous arrêtant à la première fois où il franchit 1,645, et le même système mort passe 24,25 pour cent du temps.
Prérequis : Leçon 64, pour la barre et le décompte dont elle se calcule, la leçon 19, pour la façon dont un relevé accumule des preuves, tout simplement, et leçon 62, pour la phrase sous laquelle la règle a été écrite avant que rien de tout cela ne tourne.
À quoi sert vraiment un test en avant
L’argument habituel en faveur du test en avant, c’est le réalisme : de vraies exécutions, une vraie latence, de vrais frais, aucune des commodités qu’un backtest s’accorde en silence. Cet argument est juste et ce n’est pas le principal. La leçon 63 a montré qu’un backtest soigneux peut modéliser les frais et le slippage honnêtement et rester sans valeur, et la leçon 64 a montré pourquoi : le nombre qui le discrédite n’est aucune des hypothèses de marché mais le décompte des configurations passées en audition pour le produire.
Un test en avant fixe ce décompte à un. Il tourne exactement une règle, et aucune version d’elle que vous auriez préférée ne tourne à côté pour être écartée en silence. Voilà, et non le réalisme, la propriété qui vaut d’être payée, et la leçon 64 l’a chiffrée : une configuration unique franchit à 1,645 là où une grille de 15 000 cellules doit franchir 4,499, et comme les transactions nécessaires croissent avec le carré de la barre, le relevé en direct en demande 7,48 fois moins pour dire la même chose.
Un test en avant n’est donc ni un backtest moins cher ni un backtest plus honnête. C’est la même preuve achetée dans une autre monnaie. Un backtest dépense des configurations et obtient sa réponse à l’instant ; un test en avant dépense une configuration et paie en temps. Ce que coûte le temps relève du calcul, et le voici en entier. Un avantage de d en R par transaction produit une statistique t de d fois la racine carrée du nombre de transactions, franchir la barre coûte donc 1,645 divisé par d, le tout au carré. Convertir cela en mois demande un rythme de trading, et cette page emploie partout quarante transactions par mois : un rythme qui ne se déduit de rien, seulement posé, pour qu’un lecteur au rythme différent divise le nombre de transactions par le sien.
| Avantage, R par transaction | Transactions pour franchir 1,645 | Mois à quarante par mois |
|---|---|---|
| 0,05 | 1 083 | 27,1 |
| 0,10 | 271 | 6,8 |
| 0,15 | 121 | 3,0 |
| 0,20 | 68 | 1,7 |
| 0,30 | 31 | 0,8 |
| 0,50 | 11 | 0,3 |
Lisez les deux premières lignes et la forme du problème apparaît. Les avantages que les gens trouvent réellement, une fois les frais et l’indice de référence retranchés, habitent la moitié supérieure de ce tableau, et cette moitié-là se mesure en années. Diviser par deux l’avantage que vous acceptez quadruple l’attente, parce que la barre est fixe et que seule la racine carrée du décompte monte à sa rencontre. C’est pourquoi le test en avant est abandonné : non que quiconque le conteste, mais parce que l’horizon honnête pour un dixième de R est de six mois et huit dixièmes, et que presque personne n’entame un test qu’il doit laisser tranquille aussi longtemps.
La feuille que ce module a ouverte à la leçon 62 gagne ici une quatrième colonne, et c’est la plus courte de la page : le nombre de transactions que durera le test, écrit avant la première. Presque personne parmi ceux contre qui vous tradez ne l’écrit. Il coûte un entier et un effort de retenue, et s’il manque, c’est pour la raison qui faisait manquer le décompte de configurations à la leçon 64 : s’y engager à l’avance est la seule version qui puisse vous coûter quelque chose.
Le même relevé, jugé de cinq façons
Prenez un système sans aucun avantage : 156 transactions dont les résultats sont tirés d’une distribution centrée exactement sur zéro. Faites-le vingt mille fois depuis la graine 20260903, et calculez chaque fois la statistique t courante de la manière ordinaire, la transaction moyenne sur l’erreur type de cette moyenne. Ne faites varier qu’une seule chose : le moment où vous avez le droit de regarder.
Jugé une fois, à la transaction 156 et là seulement : 5,05 pour cent de ces systèmes morts franchissent 1,645. Le test est étalonné, et c’est bien à cela que sert cette vérification — une barre censée laisser passer cinq sur cent en laisse passer 5,05 sur cent, et tout le reste se mesure à cela.
| Quand vous pouvez regarder | Regards | Systèmes morts qui passent | Transaction médiane où ils passent |
|---|---|---|---|
| Une fois, à la transaction 156 | 1 | 0,0505 | 156 |
| À mi-parcours et à la fin | 2 | 0,0795 | 78 |
| Quatre portes régulièrement espacées | 4 | 0,1187 | 78 |
| Chaque mois, treize transactions d’écart | 12 | 0,1992 | 39 |
| Après chaque transaction à partir de la vingtième | 137 | 0,2425 | 32 |
Rien dans ce tableau ne change le système, la barre, le nombre de transactions ni la distribution dont elles sortent. La seule chose qui change, c’est combien de fois le relevé a le droit d’être déclaré un succès. Quatre portes — papier, puis un quart de la taille, puis la moitié, puis la taille pleine, soit le plan de déploiement que recommande tout guide de trading systématique, y compris celui que cette page remplace — laisse passer un système mort 11,87 pour cent du temps. C’est plus du double du taux que la barre était censée permettre, et cela s’achète entièrement en regardant.
Un relevé que vous avez le droit d’arrêter est une recherche parmi des instants d’arrêt.
Ce qui veut dire qu’on peut le chiffrer exactement comme la leçon 64 a chiffré une grille. Résolvez pour le seuil qui rétablit les cinq pour cent lorsqu’on regarde après chaque transaction et il vaut 2,569. Ce n’est pas un nombre d’une espèce nouvelle : c’est la barre que la leçon 64 donne pour onze configurations. Surveiller un seul relevé en direct pendant qu’il s’accumule vaut en fouiller onze, et il en coûte 2,44 fois plus de transactions pour arriver à la même conclusion, ce qui transforme l’horizon de 6,8 mois pour un dixième de R en 660 transactions et 16,5 mois.
La version qui devrait inquiéter un lecteur menant trois systèmes candidats de front, ce qui est la manière ordinaire de tester en avant, est pire que la somme de ses parties. Trois relevés, chacun surveillé après chaque transaction à partir de la vingtième, chacun avec la même barre de 1,645 : 55,65 pour cent du temps, au moins l’un des trois se déclare vivant alors qu’aucun ne l’est. Une majorité. Le plan a l’air d’une diligence et c’est une pièce pipée en faveur de l’adoption.
Fixez donc l’horizon avant la première transaction, et lisez le relevé une fois, à la fin.
Ce que cela ne règle pas
Que les transactions soient indépendantes et identiquement distribuées. Elles ne sont ni l’un ni l’autre, et l’hypothèse travaille réellement ici : les transactions consécutives d’un même système partagent les mêmes semaines, le même régime et souvent le même risque de position ouverte, si bien que le nombre effectif d’observations indépendantes dans un relevé de 156 transactions est inférieur à 156. Cela pousse chaque horizon du premier tableau vers le haut plutôt que vers le bas, la page est donc optimiste dans la direction qui compte le plus, et elle ne dit pas de combien parce que cela dépend du système.
Que la distribution des transactions soit normale. Elle ne l’est pas, et un système à gagnantes rares et grosses a une statistique t qui converge lentement vers la normalité, ce qui rend la barre de 1,645 fausse précisément aux nombres de transactions que le premier tableau qualifie de courts. À trente et une transactions et trois dixièmes de R, l’approximation normale travaille plus que la preuve.
Que s’arrêter tôt soit le seul mal que fasse le regard. La simulation modélise une règle — s’arrêter la première fois que le relevé franchit la barre — et les vrais traders s’arrêtent aussi quand un relevé se présente mal, ce qui est la règle miroir et n’est modélisé nulle part ici. Elle écarte des systèmes qui se seraient redressés au lieu d’en adopter qui n’ont jamais marché, son coût est donc invisible et indénombrable, et rien ici ne le chiffre.
Qu’un horizon fixe soit compatible avec la tenue d’un compte. Souvent il ne l’est pas. Un système qui perd de l’argent quatre mois d’affilée devrait être coupé, et le couper relève d’une bonne gestion du risque même si cela détruit la propriété statistique sur laquelle repose toute cette page. La position honnête est que les deux objectifs entrent réellement en conflit, que la gestion du risque l’emporte, et qu’un test abandonné pour raison de risque doit être rapporté comme abandonné plutôt que consigné en silence comme un échec de l’idée.
Que l’avantage ait la même taille à la fin qu’au début. Tout ce qui précède traite d comme constant sur l’horizon, et la raison même pour laquelle un test en avant peut valoir la peine est que les conditions réelles diffèrent des conditions passées. Si l’avantage s’érode pendant que le test tourne, le relevé mesure la moyenne de quelque chose qui n’existe plus au moment où cette moyenne devient significative, et plus l’horizon est honnête, pire c’est.
Et la concession qui coûte le plus : l’horizon doit se calculer à partir de la taille d’effet, et la taille d’effet est précisément ce à quoi sert le test. Le premier tableau réclame d avant de vous dire combien de temps, ce qui est circulaire, et il n’y a pas moyen d’y échapper. Le remède le moins malhonnête est de fixer l’horizon à partir du plus petit avantage qui vaudrait la peine d’être tradé après frais, et non de celui qu’a rapporté le backtest, car ce second est le nombre dont la leçon 63 a passé une page à montrer que vous ne pouvez pas vous en servir. La leçon 66 prend le relevé qui passe et demande ce qui l’a produit, et trouve que sur les soixante clôtures de ce cours 57,7 pour cent du rendement de la règle gagnante étaient le marché et non la règle.
Exercices
- Chiffrez votre propre horizon. Prenez le plus petit avantage en R par transaction qui vaudrait la peine d’être tradé sur votre instrument après le coût aller-retour que vous avez calculé à la leçon 63, et lisez le nombre de transactions dans le premier tableau, ou calculez 1,645 divisé par cet avantage, au carré. Dix minutes, et vous repartez avec un nombre, les transactions que votre test en avant doit durer, et c’est le nombre auquel vous devez vous engager avant de passer la première.
- Comptez vos regards. Écrivez votre plan de déploiement réel — papier, petit, plus grand, plein, plus chaque revue que vous avez programmée — et comptez les points où vous pourriez décider que le système fonctionne. Une demi-heure, et vous repartez avec un nombre, le décompte des portes, que le second tableau convertit en taux auquel votre plan adopte un système qui ne contient rien.
- Faites tourner la loi nulle sur votre propre plan. Simulez un système sans avantage sur votre horizon, mille fois depuis une graine que vous écrivez, et appliquez à chaque relevé simulé vos propres portes et votre propre barre. Comptez combien de fois il aurait été adopté. Une soirée, et vous repartez avec un nombre, cette fraction, qui est le taux d’adoption à tort du processus auquel vous alliez confier de l’argent.
Sources. Peter Armitage, C. K. McPherson et B. C. Rowe, « Repeated Significance Tests on Accumulating Data » (Journal of the Royal Statistical Society, Series A, 1969), pour le résultat que reproduit le second tableau : examiner de façon répétée le même relevé en cours d’accumulation gonfle le taux de faux positifs bien au-delà de son niveau nominal. Stuart J. Pocock, « Group Sequential Methods in the Design and Analysis of Clinical Trials » (Biometrika, 1977), pour la pratique consistant à fixer d’avance le nombre de regards intermédiaires et à relever le seuil en conséquence, ce qu’est exactement le 2,569 de cette page. Peter C. O’Brien et Thomas R. Fleming, « A Multiple Testing Procedure for Clinical Trials » (Biometrics, 1979), pour l’autre voie, qui répartit inégalement le taux d’erreur entre les regards, et qui est la meilleure conception que cette page n’emploie pas. David H. Bailey, Jonathan M. Borwein, Marcos López de Prado et Qiji Jim Zhu, « Pseudo-Mathematics and Financial Charlatanism: The Effects of Backtest Overfitting on Out-of-Sample Performance » (Notices of the American Mathematical Society, 2014), pour la barre que cette leçon reprend de la leçon 64 et convertit en onze configurations.
Le prix de la recherche
La barre qu’une recherche doit franchir, et le décompte dont elle se calcule.
Lire la leçon →Combien de temps avant de le savoir
Comment un relevé accumule des preuves, et à quelle lenteur.
Lire la leçon →Le backtesting comme preuve
Pourquoi l’avantage que rapporte un backtest ne peut pas être celui dont vous fixez un horizon.
Lire la leçon →À but éducatif uniquement. Le trading comporte un risque de perte substantiel. Ceci n'est pas un conseil financier. Les performances passées ne garantissent pas les résultats futurs.
💬 Discussion (0 commentaire)
Chargement des commentaires…
Prêt à trader avec Signal Pilot ?
Mettez votre formation en pratique avec des indicateurs professionnels et des outils d'analyse de marché en temps réel.
Retour à Signal Pilot →