L'apprentissage automatique dans la négociation : théorie, modèles, pratique et algo-trading - page 297
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
apply(embed(pattern, length(signal)), 1, cor, y = signal, method = 'pearson')
Merci ! Je me demande combien de R compte comme ça. J'ai mesuré l'algorithme bible avec une longueur de signal de 1.000.000 et un motif de 100.000 - 1 seconde.
Un million de fois plus rapide ! Et alors ? Les systèmes d'échange mesurent comme des processeurs ?
Un million de fois plus rapide ! Alors, quoi ? Les systèmes de négociation sont mesurés comme des processeurs ?
Vous avez une sorte de complexe.
Non, pas un complexe.
μl et R sont des systèmes complètement différents et non superposables. Et qu'y a-t-il à comparer ? Et vous n'êtes pas le seul !
μl et R sont des systèmes complètement différents et non superposables. Et qu'y a-t-il à comparer ? Et vous n'êtes pas le seul !
Je ne m'intéressais qu'à la vitesse de réalisation d'une tâche statistique non rare dans n'importe quel langage.
R est le langage statistique le plus populaire et ses utilisateurs sont nombreux. C'est pourquoi j'ai posé la question de la comparaison ici.
L'algorithme de mise en œuvre et, par conséquent, son efficacité sont intéressants. La langue dans laquelle il est écrit n'a pas d'importance.
Je m'intéressais uniquement à la vitesse d'exécution d'une tâche statistique assez courante dans l'un ou l'autre des langages.
R est le langage statistique le plus populaire et beaucoup de personnes ici le connaissent. C'est pourquoi la question de la comparaison est posée ici.
L'algorithme de mise en œuvre et, par conséquent, son efficacité sont intéressants. La langue dans laquelle il est écrit n'a pas d'importance.
MT est un terminal de trading. Je discute donc, ici sur ce site et dans ce fil, du développement du TS. Mais nous trouvons toujours des gens qui discutent de certaines astuces de programmation qui n'ont pratiquement aucun effet sur les résultats commerciaux. La fonction de corrélation elle-même est utile dans d'autres algorithmes.
Cette fonction peut être utilisée dans les blocs de décision de trading (du moins je l'utilise) mais sa vitesse d'exécution ne joue aucun rôle, car le temps principal de calcul d'un signal de trading est déterminé par d'autres algorithmes complexes sur le plan informatique qui ne sont pas du tout présents dans mql.
C'est au stade de l'exécution.
Si l'on considère le stade de développement du TS, R est principalement supérieur à µl, car il s'agit d'un interprète, ce qui est très utile au stade où l'algorithme n'est pas tout à fait clair et où nous devons essayer de nombreuses variantes, par exemple pour comparer les corrélations des paires de devises. Sur R le temps de vérifier la corrélation est un coup sur le clavier, avec quelques lignes, dont une formation très pratique des vecteurs initiaux.
C'est ce que je voulais dire, que cela n'a aucun sens de comparer la vitesse d'exécution de ces fonctions et en général de toute autre fonction implémentée sur mcl et R.
PS.
Mais votre bibliothèque m'a évité d'étudier mcl5, merci pour cela.
MT est un terminal de trading. En conséquence, je discute, ici sur ce site et dans ce fil, du développement du TS. Mais nous trouvons toujours des gens qui discutent de certaines astuces de programmation qui n'ont pratiquement aucun effet sur les résultats commerciaux. En fait, votre question est la même car la fonction de corrélation elle-même a un sens dans d'autres algorithmes.
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 de telles choses.
Est-il préférable de consacrer un peu plus de temps au développement, mais de toujours calculer rapidement, ou de développer rapidement et de toujours supporter un calcul lent ?
Si R est rapide à développer mais lent à calculer, alors où calculer ? Pour développer rapidement une supercar qui est lente ? Vous n'avez pas besoin d'une telle supercar.
Je m'intéressais uniquement à la vitesse d'exécution d'une tâche statistique assez courante dans l'un ou l'autre des langages.
R est le langage statistique le plus populaire et beaucoup de personnes ici le connaissent. C'est pourquoi la question de la comparaison est posée ici.
L'algorithme de mise en œuvre et, par conséquent, son efficacité sont intéressants. La langue dans laquelle il est écrit n'a pas d'importance.
Eh bien, sur un signal d'une longueur de 1000000 et un motif d'une longueur de 100000, cette implémentation a peu de chances de compter dans un temps raisonnable, car il faudrait créer une matrice temporelle de 900001x100000 :D Mais il a fallu moins de 30 secondes pour l'écrire, et jusqu'à une certaine taille de tâche, elle sera tout à fait applicable. Nous pourrions faire la même chose avec fft/convolve, auquel cas nous devrions écrire plus de code, mais il serait tout aussi rapide que le code C.
En R, il est très pratique de faire des prototypes de modèles complexes - c'est son point fort. La performance du code est une question de compétences et d'expérience :
1. Certaines constructions et types de données R fonctionnent plus rapidement que d'autres (types mutables vs immuables (liste vs environnement), for vs lapply/sapply/etc., S4 vs R6).
2. la facilité de mise en parallèle dans R pour certains problèmes permet d'obtenir une solution en code lent plus rapidement qu'il ne faudrait pour écrire un code rapide dans un autre langage + calcul.
3. les opérations individuelles dans la langue sont effectuées de manière universelle, mais inefficace. Si vous implémentez des fonctions petites mais lourdes en termes de calcul en C++, vous pouvez obtenir d'excellents résultats sans réduire la vitesse de développement autant que si vous écrivez l'ensemble du code dans un langage de type C. Par exemple, l'addition d'éléments de matrice sur des lignes ou des colonnes dans R peut être 4 à 15 fois plus rapide que rowSums/colSums/apply(, 1, sum)/apply(, 2, sum).
Eh bien, sur un signal d'une longueur de 1000000 et un motif d'une longueur de 100000, cette implémentation peut difficilement être calculée en un temps raisonnable, puisqu'il faudrait créer une matrice temporelle de 900001x100000 :D Mais il a fallu moins de 30 secondes pour l'écrire, et jusqu'à une certaine taille de tâche, elle sera tout à fait applicable. Nous pouvons implémenter la même chose avec fft/convolve, auquel cas nous devrions écrire plus de code, mais la vitesse d'exécution ne serait pas trop inférieure à celle du code C.
R est très bon pour prototyper des modèles complexes - c'est sa force. La rapidité du code est une question de compétence et d'expérience :
1. Certaines constructions et certains types de données R sont plus rapides que d'autres (types mutables vs immuables (liste vs environnement), for vs lapply/sapply/etc., S4 vs R6).
2. la facilité de mise en parallèle dans R pour certains problèmes permet d'obtenir une solution en code lent plus rapidement qu'il ne faudrait pour écrire un code rapide dans un autre langage + calcul.
3. les opérations individuelles dans la langue sont effectuées de manière universelle, mais inefficace. Si vous implémentez des fonctions petites mais lourdes en termes de calcul en C++, vous pouvez obtenir d'excellents résultats sans réduire la vitesse de développement autant que dans le cas où vous écrivez l'ensemble du code dans un langage de type C. Par exemple, l'addition d'éléments de matrice sur des lignes ou des colonnes dans R peut être 4 à 15 fois plus rapide que rowSums/colSums/apply(, 1, sum)/apply(, 2, sum).