Je backteste le DAX au tick près sur 2 ans et demi.

ça sent le gastornis ça

- xxxx:
Bof: tu perds l'aspect GARCH des marchés ainsi (leur mémoire)...

D'où tout l'avantage du FHS comme cité précédement (Filtered Historcial Simulation, je vous laisse creuser) qui permet de reproduire des situations de marché avec des propriétés similaires (bootstrap des résidus + cluster de vols => garch)

Ouah! J'ai un peu regardé.
Je connaissais déjà la méthode "basique de chez basique" du bootstrap non paramétrique (qui permet grosso-modo du faire du simili Monte Carlo low cost, manuelle et simplifiée; sans même devoir se donner la peine d'utiliser un générateur de nombres aléatoires ). Mais là, ça pousse plus loin: c'est l'outil rêvé pour émuler des données réalistes, notamment pour celui qui porte une casquette de risk-manager tout en surveillant une performance .

Attention à ne citer lorsque c'est vraiment indispensable Eric( (re)voir message de bienvenue.)

Entendu Amarantine Mais à ma décharge, l'interface est tellement riche en fonctionnalités, que j'ai du mal à réfréner mon envie de les utiliser - dont la citation - sans réelle nécessité <|:o) .

Eric... oui, mais le problème, c'est que c'est illisible sur les smartphones.

D'accooooord!
C'est sûr qu'avec mes appels depuis 15 ans, avec mon Palm via une connexion Bluetooth dirigée vers mon portable 2G (compatible pages wap, tout de même), cette problématique me passait complètement au-dessus de la tête...

Bref, pour en revenir à ce que disait au début (parce que je doit dire que je comprend pas tout ce qui se dit ici en fait !) :
Après de gros espoir je viens de faire le prog pour bloquer 15min de trades avant toutes news (de 2017-2018) indiquées sur les fichiers .news sur le lien donné ci-avant. J'ai pris que les DE,FR,US, EZ : RIEN de BON !!! hélas, j'ai meme essayé +/-1 heure a cause d'une erreur GMT au cas ou.

Par contre, j'ai vraiment certaines périodes de 15min qui semblent à éviter d'une façon systématique sur 2016-18 au moins.
Mais là je tombe peut être sur de la sur-optimisation ? Test en cours !

Mais là je tombe peut être sur de la sur-optimisation ? Test en cours !

En effet prudence, l'overfitting te pends au nez

@VB6backtester: ce dont parle Robinhood, est tout simplement une méthode pour créer à minima une séries de données longue, à partir d'une petite série de données (ex.: à partir de tes 3 ans de données, comment extrapoler des séries de 10 ans de données qui soient toutes différentes mais réalistes à la fois).

@Robinhood: est-ce que tu connaitrais un framework ou une librairie orientée FHS (libre ou commerciale), permettant de programmer cette méthode plus facilement\rapidement, s'il te plait?

@VB6 : mon exérience est que les stats FR ne sont pas significatives. Et l'intérêt des les éviter dépends beaucoup de la stratégies mise en place par ton algo. Si ce n'est pas du court terme, ça ne sert à rien.

@Robin : + 1 avec Eric

@Eric/Takapoto

Etant donné l'énorme contribution de Takapoto sur Andlil je me permet de partager mon travail.

La méthode FHS nécessite de 1. mettre en place un process 2. Choisir/coder les fonctions appropriées 3. Savoir ce qu'on fait quand même (minimum de bagage en stats) et 4. Savoir où on veut aller avec ce type de modélisation

C’est un travail purement statistique. Sous R/Matlab cela se fait très facilement. Vous pouvez très probablement trouver des librairies toutes faites en VB6 ou dotnet. Voilà les étapes :

- Obtention de la série de prix cible (tick, 1 mn, 1H, daily...) à votre guise. Plus vous avez de points de données, plus cela prendra du temps, logique (toutes choses égales par ailleurs)
- Calcul des returns (arith ou log, log de préférence mais par expérience la diff est marginale)
- Vous sélectionnez un modèle autoregressif ("arima" par exemple sous Matlab) en incluant un modèle de variance (testez avec garch et ses dérivés comme egarch, etc...). Pourquoi ? Parceque vos rendements ne sont pas normaux, que les résidus tendent à être auto corrélés et avec des sauts de variances (voir garch). Le but est de reproduire à l'infini des trajectoires ayant les mêmes propriétés que votre série de rendement
- Vous estimez ensuite les paramètres de ce modèle ("estimate" sous matlab)
- Maintenant que vous avez votre modèle, vous pouvez en extraire les séries résidus + variance ("infer" sous matlab)
- Ensuite vous allez standardiser vos résidus (std_res=res/sqrt(var)). Un petit test de JB pour s'assurer que la résultante est à peu prêt normale
- Vous êtes prêt pour simuler vos trajectoires. Vous avez besoin :
* Du modèle estimé
* d'un set de valeurs de départ (par exemple : dernière valeur return de la série + dernière valeur résidus série + dernière valeur résidus standardisé). FHS requiert en effet un point de départ. C'est un détail mais c'est bon à savoir
* définir un nombre de trial (exemple 500 simus)
* définir un horizon de temps pour la simu (exemple 1 an)
- Ensuite vous créez une matrice de n lignes (n résidus standardisés) * m colonnes (= nombre de trials)
- Vous bootstrapez cette matrice pour obtenir des résidus "bootstrappés". Sous matlab, fonction "unidrnd" avec en input taille série résidus + horizon + nb trials)
- Dernière étape : à partir de votre matrice de résidus bootstrappés, vous allez estimer une matrice de rendements qui aura n ligne de rendements simulés (horizon) * m colonnes (nbtrial)

Une fois que vous avez vos rendements, vous pouvez simuler une série de prix puis de bougies, d'indicateurs, etc... .

Exemple ci-dessous avec le SP500 en daily (300 jours, 500 trials).

Donc voilà, l'énorme avantage de cette méthode c'est de pouvoir simuler des trajectoires en conservant 1. Les propriétés statistiques de la série et 2. D'utiliser les résidus existants au sein de cette série. FHS tire donc des trajectoires de rendements sous contrainte de 1 et 2.

Conseil : en référence à ce que j'ai évoqué dans un précédent message : calcul matriciel indispensable et parallélisation conseillée.

En espérant vous avoir éclairé sur le sujet

N'hésitez pas.

Impressionant !
Un grand

@Robinhood: un très grand merci également , et je suis aussi impressionné!

Pour apporter ma petite pierre à ce fil...: la programmation décrite par Robinhood nécessite un serveur de calculs genre interpréteur R-Cran. Bon, j'espérais que Robinhood utilisait un bibliothèque en C++ ou Java. Je n'ai rien contre R-Cran (il est gratuit et sait faire tout ce que font Mathématika, Matlab & co), mais:
a) sa "learning curve" est chronophage: R-Cran est vaste (maintenant, la seule connaissance des 2 ou 3 biblios de finance\trading surtout orientées calculs sur séries temporelles et l’accès aux fichiers texte devrait suffir; c'est en tout cas ce que j'espère).
b) je ne le conçois que comme un serveur de calculs: fichier data-input-texte en entrée et appelle de l'interpréteur R-Cran avec en commutateur l'emplacement dudit fichier et le script de calculs à appliquer dessus, puis récupération d'un fichier de data-output-texte ou d'un joli graphique, s'il le peut.

Cette solution présente l'avantage de laisser chacun avec son langage "fétiche" compilable donc probablement plus véloce que l'interpréteur d'R-Cran, langage "fétiche" car probablement accompagné d'un *vrai* compilateur - je veux dire permettant de surveiller le processeur, Robinhood décrivant sa programmation comme "sportive" - qui permette facilement de paralléliser et déboguer des tâches comme créer les fichiers data-input-texte d'entrée en amont, voire des pré-sérialisations des calculs par matrices aussi (?): je ne connais absolument pas les capacités de calculs matriciels de R-Cran; ce qu'il le peut facilement faire ou pas; s'il le peut alors c'est plutôt lui qui le ferait). De toute façon, je ne demande qu'à être agréablement surpris par les capacités d'R-Cran, mais je préfère rester circonspect plutôt que de partir "bille en tête" et de baser tous les aspects de la programmation dessus .

Dans une telle architecture logicielle, R-Cran est ainsi isolé de chaque langage de programmation, de toute communication avec un système de stockage, et ne sert à créer aucune interface. In fine, R-Cran est donc utilisé juste pour ce qu'il sait faire de mieux: seulement les calculs plus poussés que la moyenne.

Je vais de toutes les façons devoir m'y coller (des amateurs?)...

@Eric

- Non tu peux le faire avec n'importe quel pc
- Tu as juste besoin des bonnes librairies. Pour info il y a des compilateurs qui existent pour R, Matlab, Python..qui te permettent de créer tes propres dll pour ensuite les appeler en c,c++,VB,c#...

Tu peux ensuite avoir un besoin important niveau calcul, dans ce cas là tu peux passer par une solution EC2 ou equivalent.

Pour ma part jai investit pas mal ce qui me permet d'être autonome niveau calcul. Ça me paraît indispensable dès l'instant où on code des strats et qu'on lance des backtests à répétotoon

Merci Robin, Eric. J'ai mis de côté le trading personnellement, mais je compte y revenir début 2019. pour vos partages.

Vous êtes de vrais scientifiques ici ! Je comprends pas la moitié de ce que vous dites !
Vous avez utilisé des EC2 ? c'est du computing à distance ? Ca va vraiment plus vite qu'un iCore 7 à 3.4ghz ???
Bye

Pour ma part je ne me qualifie nullement comme scientifique, plutôt comme "débrouillard touche à tout" et surtout avec une bonne dose de "fendardise"

Sinon pour revenir à l'essentiel :

- Jamais utilisé EC2 ou équivalent. Trop prohibitif et pas envie d'envoyer mes données sur des solutions externes. En gros tu à accès (à distance) à un ou plusieurs serveurs distants (on parle alors de "pool") sur lesquels tu vas paralléliser un très grand nombre de tâches similaires. Par exemple un grand nombre de backtest avec x paramètres sur y actifs sur un horizon z, etc...
- Alternativement, j'ai monté mon propre serveur et upgradé ma machine de dév (mon pc fixe) en mettant le paquet (on parle d'un total proche des 5K€). Résultat je suis capable de lancer et d'avoir des résultats hyper rapidement sur un très gros set de données et plein d'actifs, sur plusieurs années..
- Bien entendu c'est très pratique pour les tâches parallélisables. Avec ton core i7 3.4 cela doit être un 2600 ou un 2600k=overclockable) tu as 4 coeurs physiques soit 8 threads. Cela te permet déjà de paralléliser des calculs jusqu'à 8 coeurs (en pratique plutôt 7 car il y a un point d'inflexion optimal avec d'utiliser la charge maxi du cpu)
- Par ailleurs, la puissance de calcul en single thread est dans tous les cas nécessaire pour tester des petites tâches ou segments de code (et de façon générale toute tes applis en single tread). Il faut aussi savoir que lorsque tu fais du calcul parallèle sur cpu (je ne parle pas ici de calcul parallèle sur gpu, beaucoup plus limité en termes de possibilités mais pour des opérations simple => extrêmement efficace), les coeurs de ton cpu (multi-threading) tournent "moins vite" qu'en single tread

C'est fabuleux de voir qu'il y a des gens comme vous !
Mais sinon en terme de rapidité, je suis certain que si je repartais à zéro en C++ ou Delphi au lieu de VB6 je pourrai déjà aller plus vite. Mais j'ai tj eu la flemme jusqu'à présent....
Je crois que je vais plutôt passer un peu de temps à utiliser réellement ce parralélisme en faisant une distribution automatique des backtest sur 6/8 processs. Pour l'instant je fais à la main, et à la louche suivant la lourdeur du test.

Tu fais des backtests sur plusieurs actifs corrélés ???

Bye