L'apprentissage automatique dans la négociation : théorie, modèles, pratique et algo-trading - page 298
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Est-il préférable de consacrer un peu plus de temps au développement et de toujours calculer rapidement, ou de développer rapidement et de toujours supporter des calculs lents ?
Si vous développez rapidement en R mais que vous êtes lent à faire des calculs, où voulez-vous faire les calculs ? Rapide pour développer une supercar qui est lente à conduire ? Vous n'avez pas besoin d'une telle supercar.
Dans les tâches de recherche, c'est la vitesse de développement qui est au premier plan. Au lieu d'une personne qui écrit un code super rapide mais teste une hypothèse par jour, une personne qui écrit un code lent et effectue des calculs toute la nuit, mais qui a testé 20 hypothèses le lendemain, est facilement embauchée.
Pour la production et la mise en œuvre du modèle, il est plus facile d'engager une autre personne avec un petit salaire, qui réécrira les modèles les plus prometteurs dans le langage le plus rapide possible. Il y a beaucoup de programmeurs et la concurrence est forte, mais les chercheurs qui peuvent proposer quelque chose de nouveau sont difficiles à trouver :P
C'est une pratique courante. Recherchez des emplois de chercheur quantitatif et de développeur quantitatif. Les premiers ont généralement besoin de R/Python, les seconds de C++/Java.
Dans les tâches de recherche, c'est la vitesse de développement qui est mise en avant. Au lieu d'une personne qui écrit un code super rapide, mais vérifie une hypothèse par jour, une personne qui écrit un code lent et effectue des calculs toute la nuit, mais le lendemain, elle a vérifié 20 hypothèses.
Pour la production-mise en œuvre du modèle, il est plus facile d'engager une autre personne pour un petit salaire afin de réécrire les modèles les plus prometteurs dans un langage rapide. Il y a beaucoup de programmeurs, et la concurrence est forte ; mais les chercheurs qui peuvent proposer quelque chose de nouveau sont difficiles à trouver :P
C'est une pratique courante. Recherchez des emplois de chercheur quantitatif et de développeur quantitatif. Les premiers doivent généralement connaître R/Python, les seconds doivent généralement connaître C++/Java.
Ne serait-il pas plus facile d'utiliser des bibliothèques C++ prêtes et rapides au lieu d'utiliser les mêmes mais lentes en R pour un "développement rapide" ? Vous, et beaucoup d'autres ici, faites constamment une substitution de notions. Vous pouvez "développer rapidement" dans un environnement de type C de la même manière. Ou vous n'avez pas besoin de connaissances appropriées en matière d'extraction de données et de statistiques pour travailler avec R ? De la même manière, vous devez avoir les connaissances nécessaires pour développer en C. Alors pourquoi faire un double travail ?
Et je ne sais pas de quel genre de "pratique normale" vous parlez, mais j'ai l'habitude de bien faire les choses une fois pour toutes.
Au cours de ma pratique de l'ingénierie, j'ai souvent vu des gens qui, pour une raison ou une autre, pensaient que s'ils utilisaient un logiciel super facile à développer, ils allaient certainement réussir... Mais ils n'ont pas compris une chose : ils ont besoin d'une autre chose pour que tout fonctionne bien : la graisse dans leur tête.
N'est-il pas plus facile d'utiliser des bibliothèques C++ standard et rapides que d'utiliser les mêmes mais lentes dans R pour un "développement rapide" ? Vous, et beaucoup d'autres ici, faites constamment une substitution de notions. De la même manière, vous pouvez "développer rapidement" dans un environnement de type C.
Le choix du langage est votre droit et votre affaire personnelle. En ce qui concerne les bibliothèques - hélas, pour tout algorithme moderne ou inhabituel, vous devez tout implémenter vous-même. Par exemple, pour calculer la "variance bipolaire" (qu'est-ce que ça veut dire ? :D) je n'ai pas trouvé de bibliothèques.
Ou bien il n'est pas nécessaire d'avoir des connaissances appropriées en matière d'extraction de données et de statistiques pour travailler avec R ?
Je ne le prétends pas et je ne soutiens pas cette opinion.
Et je ne sais pas de quel genre de "pratique courante" vous parlez, mais j'ai l'habitude de bien faire les choses une fois et une seule.
Au cours de ma pratique d'ingénieur, j'ai souvent vu des gens qui, pour une raison ou une autre, pensaient que s'ils utilisaient des progiciels super faciles à développer, ils allaient certainement réussir... Mais ils ne comprenaient pas une chose - ils avaient besoin d'autre chose pour que tout soit bon : la graisse dans leur tête.
Ma pratique dans certains projets d'une complexité de ## années-homme, où 95% du code est écrit en R, montre que différents outils sont bons pour différentes tâches, parfois même des tâches lentes, tant qu'ils sont utilisés pour des prototypes et non pour la production. L'utilisation de différents outils à différents stades du développement est une pratique courante dans l'industrie du développement et est confirmée par les besoins en spécialistes pour différentes tâches. Les projets que j'ai mentionnés seraient devenus beaucoup plus complexes s'ils étaient mis en œuvre dans un langage de type C, même par des soldats universels qui savent et peuvent tout faire et écrire la solution au problème en une seule fois, sans aucune phase de recherche.
Je prends donc congé.
N'est-il pas plus facile d'utiliser des bibliothèques C++ standard et rapides que d'utiliser les mêmes, mais lentes, dans R pour un "développement rapide" ?
Lorsque je discute de R, je m'en tiens toujours à une évaluation complète et systématique de ce "système graphique et statistique". Le langage algorithmique lui-même n'est pas du tout mentionné dans le titre.
Une comparaison frontale des performances d'un code en R et d'un code en µl, ou en un autre langage de programmation, sur un exemple spécifique et local n'est absolument PAS correcte, car TC ne consiste jamais, comme nous l'avons vu plus haut, en une fonction de corrélation, mais est toujours un grand ensemble composé de code et d'appels de fonctions. Comme R dispose d'un grand nombre de fonctions, le code a généralement un petit nombre de lignes (1000 lignes, c'est beaucoup), mais un contenu très important.
Le programme lui-même, qui résout un problème important, peut être divisé en deux parties :
En ce qui concerne le point 1, si des quantités importantes de code ont dû être écrites, le problème de la vitesse peut être très grave. Il y a trois façons de la surmonter :
En ce qui concerne le point 2, les performances sont tout à fait différentes et je doute que, sans efforts particuliers dans le développement habituel du programme µl, il puisse surpasser R en termes de performances.
Par exemple.
En apparence, les opérations sur les vecteurs et les matrices dans R sont basiques. Une expression de la forme a <- b*c est exécutée par la bibliothèque Intel. Il n'y a pas de boucles. Il est à la disposition de tous, aucune connaissance ou effort supplémentaire n'est requis. Lors du développement d'un programme μl, des cycles seront très probablement utilisés, bien qu'il soit également possible de se référer à la même bibliothèque (si le programme n'est pas destiné au marché), mais un niveau assez élevé de connaissances et d'efforts est nécessaire pour obtenir le même résultat.
Mais ce n'est pas tout.
Si nous abordons les algorithmes lourds en calcul, et ce sont des appels aux fonctions R, le développeur lui-même, confronté au problème des performances, s'est préoccupé de ce problème et l'a généralement résolu au stade du développement. Ce problème est généralement résolu soit en écrivant du code C, soit en faisant référence à des bibliothèques C ou Fortran. En outre, ces algorithmes ont parmi leurs paramètres la possibilité de spécifier l'utilisation de plusieurs cœurs. Un développeur en R obtient tout cela automatiquement sans aucun effort. On peut se concentrer pleinement sur l'essence de la CT, et non sur la technique de mise en œuvre. Il est douteux que le développeur de μl-programme puisse surpasser le développeur de fonctions dans R pour la raison triviale - il est nécessaire de travailler spécifiquement sur la performance, mais pas sur l'essence de la CT.
De tout ce qui a été écrit, il résulte qu'une comparaison correcte des performances consisterait à écrire le code TC réel sur µl et le même code sur µl+R (il n'y a pas d'ordres de commerce dans R) et de comparer. Mais dans toute sa splendeur - en avons-nous besoin ?
Quelqu'un a-t-il essayé de travailler avec des diagrammes de récurrence ? Vous pouvez le lire icihttps://habrahabr.ru/post/145805/, en particulier pour remplacer les BP bruts par des MO ? Cela pourrait être une option.
et d'autres à lirehttp://geo.phys.spbu.ru/Problems_of_geophysics/2005/20_Zolotova_38_2005.pdf
Une idée pour ceux qui peuvent la mettre en œuvre. La vision artificielle compare ces tracés en recherchant des correspondances entre les modèles. En remplacement d'une corrélation inutile
Une idée pour ceux qui peuvent la mettre en œuvre. Comparaison par vision artificielle de ces tracés à la recherche d'une correspondance de motifs. En remplacement d'une corrélation inutile.
Auparavant, certaines idées ne pouvaient pas être testées par le CT, car elles étaient entravées par les faibles performances de certains algorithmes. Dans ce cas, c'est exactement ce qui s'est passé - un algorithme alternatif a permis à l'optimiseur d'explorer une idée vieille comme le monde, mais qui ne pouvait pas être calculée auparavant dans un temps raisonnable.
Lorsque l'on doit calculer des centaines de milliards de QC de Pearson dans des motifs de quelques milliers de longueur, la faible vitesse d'une tâche apparemment simple devient un goulot d'étranglement insurmontable. On pourrait commencer à dire que si un problème semble trop lourd sur le plan informatique, il s'agit d'un problème mal formulé et peu compris. Peut-être que c'est le cas. Mais ce qui est fait est fait. Et il est toujours intéressant de voir comment les autres mettent en œuvre des choses similaires.
Et si vous l'implémentez également sur GPU, vous serez vraiment précieux)).
Sans ponzi, vous pouvez trouver le modèle le plus fréquent. Mais quel est l'intérêt ?
Bien sûr, pour un modèle de stratégie, ce n'est pas nécessairement le plus fréquent, il peut y avoir de nombreuses variantes.
Ce n'est pas nécessairement le plus fréquent pour les stratégies de modèles, il peut y avoir de nombreuses variantes.
C'est ce que je ne comprends pas. L'utilisation de données de motif est utile pour la compression de données avec une faible perte d'informations (divers supports). Mais qu'est-ce que cela a à voir avec le CT ?
La façon la plus simple de parler de ce sujet est d'utiliser le motif le plus fréquent comme exemple. Il n'est pas difficile de le trouver.
Voici une énigme (schéma) qui revient le plus souvent. Son critère de sélection n'est pas si important pour le moment. Que l'énigme soit là. Comment l'utiliser pour le trading ?
Dire que si une histoire extérieure coïncide avec une zagguline dans les premiers 80%, alors les prix suivants suivront le même schéma que les 20% restants de la zagguline est un non-sens.
C'est ce que je ne comprends pas. L'utilisation de données de motif est utile pour la compression de données avec une faible perte d'informations (divers supports). Mais qu'est-ce que cela a à voir avec le CT ?
La façon la plus simple de parler de ce sujet est d'utiliser le motif le plus fréquent comme exemple. Il n'est pas difficile de le trouver.
Voici une énigme (schéma) qui revient le plus souvent. Son critère de sélection n'est pas si important pour le moment. Que l'énigme soit là. Comment l'utiliser pour le trading ?
Dire que si une histoire extérieure coïncide avec une zagaguline dans les premiers 80%, alors les prix suivants iront dans le même sens que les 20% restants de la zagaguline est un non-sens.
Pourquoi pensez-vous que c'est un non-sens ? si la prévision se confirme, sur la même histoire, dans une masse de cas