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

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

Je prend bonne note , même si je n'ai pas encore le temps (ce soir) de faire des calculs d'histo plus poussés, mais à première vue (volatilité+spread) je pense de suite au DAX....

Oui tu verras que le DAX est très bien positionné, tout comme le DOW, sans oublier certaines paires....

Et tu as essayé la moyenne de Hull ? Je viens de tester et j'ai pas grand chose de bon. Etrange comme certaines moyennes marchent mieux que d'autres qque soit la période....

MM simple, expo, tri, Hull et j'en passe (et en faisant varier k paramètres) ce n'est certainement pas cela qui va te permettre de passer d'une strat perdante à une strat gagnante.

Ce sont les choses les plus simples qui marchent le mieux.

Pose toi la question : que cherches tu à "jouer" sur le marché ? Quelques exemples :

- breakup/breakdown
- pullback
- rebonds ou recharges sur PP/figures
- contrariant sur surachat/sur vente
- etc....

Tu ne pourras pas jouer tous ces types de stratégies avec une seul strat. Donc choisi un type et travaille dessus. Tu veras que selon les strats, les meilleures combinaisons d'indicateurs (encore une fois simples, pas besoin de sortir le sapin de noel) varient d'une strat à l'autre et il y a de la logique la dedans.

Ai à l'esprit que les strats les plus robustes fonctionnement indépendamment des ut et des sous-jacents traités.

Par ailleurs il vaut mieux avoir plusieurs stratégies "moyennes" agrégées qui gagnent peu sur le long terme mais qui sont décorélées plutôt qu'une seule strat qui gagne autant sur le long terme.

Une des clés de réussite en Finance c'est la diversification. "The only free lunch" comme disait l'autre

Je suis assez d'accord avec toi mais que ce soit une moyenne ou autre chose, tu as toujours besoin de régler des choses des durées au moins... Pour la diversification, je vais yrepenser mais jusqu'à présent j'ai l'impression que tout est lié. Le dax tremble avec le Dow dès que Trump s énervé.

Je faisais surtout référence au fait de diversifier en prenant plusieurs strats sur plusieurs ut à minima. Après bien entendu chacun sa popote

Et que penses tu des "trailing stops" ?

Je pense qu'il y a un intérêt à les utiliser en prenant en compte :

- La vol
- Les niveaux éventuels que le cours peut traverser une fois que tu es en position

Leur gestion doit donc être dynamique. Je n'ai pas constaté de miracle en statique.

Quand tu dis 'statique' c'est que le stop ne bouge pas une fois fixé? pour l'instant je n'ai rien trouvé de bon en faisant autrement. D'après mes backtests j'en arriverai (pour le moment) à une conclusion purement statistique : que si tu remontes ton stop en 'dynamique' ou dès le départ ne change rien. Le niveau est modifié , point à la ligne.... et donc si tu le diminue , tu risque des stops plus nombreux c'est tout.
Mais en fait je pense que les T.Stop sont valables si on laisse courir les gains au-dela de plusieurs dizaines de pips.

Quand je dis statique cela fait référence au fait de définir (pour un même actif) un stop identique peu importe les conditions de vol et de niveaux de prix.

En effet le risque sur les stop suiveurs c'est celui de se faire stopper inutilement. De la même façon que les stops classiques, les stops suiveurs doivent fonctionner de façon générale mais là encore, pour ma part, la distance doit être fonction des conditions de vol et de niveaux de prix.