Bonjour !
Content de voir que vous avancez, pour ma part je ne fais que de la maintenance faute de temps, aussi bien pour le code (les mises à jour de pandas/matplotlib cassent parfois des choses) que pour les données (les scrapers ont parfois besoin d’être modifiés pour coller aux évolutions des sites, ainsi va la vie) donc rien de bien intéressant à poster de mon côté.
Je me suis heurté aux mêmes écueils pour Pronostix, mon programme de backtest, je vais donc répondre à vos questions même si je rejoins l’avis de sven337 : il vaudrait sans doute mieux utiliser une lib existante et maintenue, pour bénéficier du travail d’optimisation et de debug collectif.
Mes données (29 ans de cours, sur les seules actions) sont dans une base Postgresql, donc le découpage des fichiers de cotations importe peu. Si vous faites un read_csv() pour chaque fichier ça peut ralentir tout votre processus, en tout cas ça sera beaucoup plus lent et compliqué que de lire depuis une base de données quelconque.
La méthode la plus rapide que je connaisse pour itérer sur une dataframe est for row in df.itertuples(name=None):, mais on perd les noms des colonnes au passage. Rien d’insurmontable, mais ça rend le code dépendant à l’ordre et au nombre des colonnes.
Pour gagner en vitesse d’exécution il y a bien PyPy - Welcome to PyPy mais il vaut mieux bien maîtriser Python avant de s’y lancer, il y a souvent des soucis de compatibilité ou des différences comportementales. Le jeu en vaut toutefois la chandelle, sur des programmes qui doivent faire beaucoup d’opérations sur une durée un peu longue le JIT est efficace.
Pas de raison qu’un type de programmation soit plus adaptée qu’un autre, dans un cas on allouera des classes dans l’autre on empilera des appels de fonctions. Pronostix est orienté objet (une classe Broker, une classe Portfolio, une classe Strategy de laquelle sont dérivées une classe par stratégie testée…), et n’irait pas plus vite en fonctionnel.
Un truc qui peut faire la différence, par contre : toujours utiliser les opérations vectorisées de pandas/numpy au lieu de faire les calculs soi même, typiquement pour le calcul des indicateurs techniques comme les moyennes mobiles.
Tant que le CPU ou le disque de votre machine n’est pas à 100%, vous ne gagnerez rien à scinder vos calculs sur deux machines à part de nouveaux problèmes (le réseau va ajouter de la latence, par exemple).
sven337 a écrit :
Pourquoi récrire votre propre code de backtest ? Il existe des bibliothèques qui font ça bien, par exemple bt/ffn. Je suis certain qu’il y en a plein d’autres.
Je vais compléter en citant zipline, qui est assez réputée. Quantopian fournit également tout un environnement de backtest accessible et performant, je vous conseille d’y jeter un oeil.
sven337 a écrit :
Écrire correctement ce genre de chose est difficile.
Très difficile ! D’ailleurs en parlant d’overfit, attention à ne pas inclure par mégarde de l’information du futur dans votre jeu d’essai ou vos calculs, ça arrive plus vite qu’on ne le croit et c’est aussi difficile à détecter qu’à corriger… ça m’est arrivé sur un réseau de neurones qui avait des résultats trop beaux pour être vrais, comme c’est souvent le cas 
Have fun !
Membres
Hors ligne
1 
