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

@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

Certes de façon générale c++ est probablement ce qui se fait de plus performant. En revanche, avec de bonnes pratiques (déclarations des variables en amont, calcul matriciel au lieu de boucles, fonctions et non répétotoons inutiles de segments de code, etc...) tu peux gagner énormément en temps de calcul et en efficacité.

Pour infos je fais tous mes dévs/backtests sous Matlab et pour la prod je fais en .Net (c#).

Je ne peux que te conseiller matlab pour la partie backtest mais tu as aussi R et surtout Python qui sont gratuits et efficaces et qui embarquent des librairies de calcul parallèle.

Enfin étant purement sur des stratégies intraday actuellement je traite tous les actifs indépendamment les uns des autres (pas dans un contexte portefeuille donc). Sur de très courts mouvements (scalps), je favorise les actifs très peu corrélés (voir orthogonaux).

Bien évidemment il y a des strats utilisant/controllant les correls à très court terme en temps réel (intraday) qui ont du potentiel (c'est jute un type x de strats sur un horizon de temps y).

Pour ce qui est des actifs : les plus liquides, les moins spreadés (relativement à leur niveau et à leur amplitudes quotidiennes moyenne), et idéalement les moins corrélés possible.

je suis certain que si je repartais à zéro en C++ ou Delphi au lieu de VB6 je pourrai déjà aller plus vite.

Pour info., Delphi devient gravement "has been" ==> ces 10 denières années, ils se sont faits racheter x fois et sont partis à chaque fois dans de nouvelles directions de développements douteuses: dév. pour Linux puis abandon, puis reprise, puis délaissé, et puis quoi ensuite?; dév. pour tél. portable iPhone avant Androïd qui est pourtant nettement plus répandu, etc, etc. Ils en sont arrivés à un point où ils incluent maintenant du free Pascal dans leur VCL, qui est leur framework interne (il existe aussi un framework externe open source nommé Jedi, dont le sous-framework JCL est hautement compatible avec "Laz"). Conséquence: de nombreux développeurs l'ont quitté et sont passés à "Laz" (Lazarus). De même, tous les éditeurs-"cadors" de suite de composants pour créer des charts (TCharts), des composants poussés orientés éditeurs de texte, etc migrent tous leur code source vers Laz. Lazarus il est gratuit. C'est le même EDI que Delphi; il vaut un Delphi XE1. Tout y a été transposé pour faire du RAD-BDD en MVC aussi rapidement que Delphi: Zeos & d'autres accès BDD, TDatabase, TConnexion(s), TMemoryDataset, TDatasource, TQuery , etc, etc). Si tu connais Delphi, tu t'y retrouves très vite.

[HS info]
@Robinhood: j'ai fureté dans les docs de R.
A moins d'être passé à côté de quelque chose, son architecture originelle est que son langage officiel est bel et bien un langage interprété par dessus un interpréteur écrit en C++ j'imagine (comme php, etc). Ceci donne donc "le LA" sous R: ainsi, ce sont donc les nouvelles biblios thématiques de calculs validées et publiées qui font le buzz avec cet outil, quitte à ce que des ajustements de l'interpréteur R en C++ aient été faits du fait des nouveautés desdites nouvelles biblios de scripting destinées à être utilisées d'abord et avant tout avec le langage officiel de R. Ces nouvelles biblios thématiques de calculs sont "le fer de lance" de R, dans le contexte originel de R: écrire des scripts interprétés. Je radote, mais c'est amo important avant de partir dans une solution "wrappeur" ou "pont" ou "adaptateur".
Je vais encore radoter en répétant qu'attendu que c'est le langage officiel de R qui est le fer de lance de R puisque c'est lui qui est le premier à pouvoir bénéficier de nouvelles intégrations de biblios thématiques de calculs, tout le reste (pouvoir compiler des dll, etc, ne sont que des ponts, des enveloppes autour de R; au passage, j'ai lu que déboguer une dll compilée se fait via l'appel à des fonctions comme debug, print, etc ; bref, autant laisser le code R natif en texte-script et le déboguer ainsi: le passage par une dll ajoute une complication dont je préfère me passer d'autant qu'on est loin des possibilités d'un langage possédant un compilo. qui peut s'attacher à une dll et y voir l'enchaînement de ses registres, piles d'appels etc du processeur...).

Je n'ai pas un DEA de parallélisation.
Donc mon point de vue est d'être ultra-pragmatique en partant de l'essence-même de R: un superbe interpréteur de scripts orientés calculs. Partant de là, j'ai vu que R mettait à disposition un outil RScript.exe (y'a son alter-ego pour Linux) qui peut paralléliser: RScript.exe peut être lancé en instance parente depuis un programme client: dans le début du script "de-tête" appelé en commutateur de RScript.exe-parent, on peut y coder des fonctions pour déterminer le nombre de processeurs et de cœurs de la machine locale, et on peut créer des instances-filles RScript.exe de l'instance parente RScript.exe (en gros: le nombre de cœurs -1 laissé au progr. client).
Ensuite, il y a aussi des biblio. qui ont des paramètres dans leurs fonctions pour leur permettre de faire du threading "en sus" ('me reste à déterminer où vont ces thread: j'imagine vers une instances-filles RScript.exe, mais je n'en sais rien en fait: pas assez de connaissances de R; c'est pas en 4..6 heures que je vais pouvoir avoir l'esprit clair quant à ce vaste outil ).
D'autre part, j'ai lu que passer des matrices conséquentes à RScript via un\des file(s)-texte-data-inpout ne semble pas poser de problème (d'autant plus si on a un disque dur SSD): certains le font.

Voilà: c'est seulement ma façon de voir la chose en tant que novice. Si d'autres ont des expériences réussies avec une architecture logicielle efficiente pour la parallélisation, qui inclut un programme client et le serveur de calculs R, qu'ils n'hésitent pas .
[/HS info]

Merci Eric je pense que cela peut intéresser des forumers qui codent sous R.

R a tout les avantages (et défauts) de l'open source alors que Matlab (pour rappel solution payante) est beaucoup mieux fini (et convivial pour avoir comparé les 2).

In fine chacun trouve chaussure à son pied et c'est l'essentiel. Juste pour recentrer sur la problématique de calcul, la règle universelle c'est ce que c'est d'abord au niveau du code et de sa structure que les plus gros gains de productivité sont atteins. Le hardware permet ensuite de "leverager". Mais leverager un code foireux cela ne que peut d'intérêt

Ok, merci Robinhood .

Robinhood: en furetant dans R, j'ai donc vu que l'instance RScript.exe-parente pouvait créer autant de workers-instances-RScript.exe-filles ==> donc, je me dis que c'est plutôt de la programmation "fat-parallélisation-côté-serveur-de-calculs"... pour les calculs .

Je sais que tu utilises Matlab.

Tu dis: "la règle universelle c'est ce que c'est d'abord au niveau du code et de sa structure que les plus gros gains de productivité sont atteints."

Là, j'imagine que tu parles de ton code Matlab (je laisse de côté le choix optimal des structures de stockage côté client, chacun avec son L4G préféré)?
Et pour t'embêter encore: est-ce que tu pourrais dire que la parallélisation de ton code côté C# est marginale par rapport à celle côté Matlab ('suis pénible, je sais )?

Non paralléliser est bien plus simple que cela en a l'air, dès l'instant où on accepte de mettre les mains dans le cambouis. Comme évoqué je parallélise même sur mon pc portable quand je suis en déplacement et que j'ai besoin de tester des petites choses.

Il est clair que sous matlab c'est très bien Fichu donc gain de temps non négligeable pour la mise en place du setup. Attention cela demande à repenser la manière d'organiser le code. Le must est de pouvoir switcher facilement en mode single vs multi-tread (parallélisation) au niveau du code. Il faut aussi avoir à l'esprit que paralléliser nécessite de respecter certaines contraintes niveau code. Etc...

Sous R, Python ou autre, je ne pense pas que cela soit bien compliqué. On est en 2018. C'est monnaie courante de nos jours chez les quants.

Lors des backtests, pour ce qui est du stockage, évidemment tout intérêt à stocker en local sur un SSD et au max via la mémoire.

Enfin à noter que pour le moment je ne parallélise pas en C# car je ne suis pas encore en prod/réel mais lorsque cela viendra, tout dépendra du nombre d'actifs traités en temps réel. A voir déjà en prod/démo comme cela se comportera. Mais je pense qu'en single tread je serais vite dépassé. Tu imagines le process : réception de données en temps réel>analyse>prise de décision>ordre envoyé si nécessaire, tout cela dans le temps le plus court possible (200ms à 1 SEC max all-in). Donc ça même sur 5 actifs ça envoi quand même un bonne charge. Mais à voir en effet...

En ésperant t'avoir éclairé, et non tu n'es pas pénible (tu plaisantes ?)

J'arrête là mes questions: 'faut que je passe à la pratique en mettant aussi mes mains dans le cambouis. Tes explications m'ont plus qu'éclairé ==> elle m'ont ébloui, Robinhood!

Bonsoir Robinhood, sans vouloir te demander tes secrets, tu parles du "nombre d'actifs" : cela signifie que tu backtestes des EA avec plusieurs valeurs liées en simultané ?

Hello!

Pour ma part je ne parle pas d'EA mais de stratégies ("strats" pour le diminutif) mais peu importe

Au niveau du backtest si il y s'agit d'une strat faisant appel à un portefeuille d'actifs (indépendamment de la période, de l'intraday au très long terme) alors oui => backtest en simultané, i.e prise en compte de tous mes actifs à l'instant t du backtest.

Maintenant s'il s'agit simplement de généraliser un test fait sur 1 actif (indépendamment des autres), i.e cas d'une stratégie mono-actif pure, je peux tester par exemple sur une période précise sur x actifs ou bien sur l'historique max de chaque actifs, sans que cela soit en même temps car pas d'intérêt.

Par exemple pour une strat live intraday, la même strat tournera indépendamment sur chaque actifs. Le seul point de liaison éventuel étant la gestion des appels de marges (zéro en intraday) et des couvertures. Par exemple j'ai 25K et je veux traiter des lots plein sur DAX, NAS, DOW, F.T.S.E, CAC, et bien je ne pourrais pas avoir en même temps un contrat sur chacun de ces actifs (pas assez de K pour la couverture globale). Donc il faut bien discriminer pour savoir quel actif tu favorise par exemple. Ceci se fait à travers un moteur d'allocation. Par exemple favoriser la diversification (alors si tu prends que des indices actions ton pouvoir de diversification est globalement faible, mais si tu croises les paires majeures, les principaux taux, quelques matières premières et indices actions, tu peux avoir un bon portefeuille bien diversifié, en particuliers en intraday car sur du très court terme).

Hello Robinhood ! Puisque tu parles du CAC, j'ai fait qques simul dessus et j'ai vite arrêté par manque de volatilité...c'est vraiment plat tu trouves pas ? J'avais des résultats bien mieux sur le DOW mais par contre trop chaotique (enfin plus que le DAX) et j'ai fini par faire que le DAX, en me disant que ça sert à rien de se diversifier avec des trucs qui marchent moins bien.
Je me suis plutôt diversifié en faisant + de strats réglées différemment sur le DAX.
C'est pas mal non ?

En réponse à ta 1ère question tu viens de poser indirectement la problématique suivante : quels actifs traiter (et dans quel ordre de priorité) ?

Un bon indicateur pour aider est là prise en compte du ratio : range moyen intraday / spread. Par ailleurs je pars du principe qu'on ne considère que des actifs très liquides et qu'on se limite à un horizon intraday only.

Calcule le déjà sur tes historiques de données ppur les actifs que tu as à disposition. Y'a quelque chose qui va te sauter aux yeux