L'Apprentissage Automatique dans le trading : théorie, modèles, pratique et trading algo - page 220
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
Il y a beaucoup de mots, mais l'essentiel ....., peut-être qu'il n'accroche pas, quant à moi l'homme s'est juste plaint un peu)).
Le fait est qu'il ne faut pas s'encombrer de "sucreries" sous la forme de R, Matlab, python etc. De toute façon, après cela, tout sera converti en C++, et ce processus est presque indépendant, le code R n'est pas un prototype de C++. Les gens s'accrochent à toutes sortes de RAD et se mordent ensuite les coudes, il leur faudra 2-3 ans pour se débarrasser de leurs mauvaises habitudes, si une personne se rend compte qu'elle s'est engagée dans une impasse, bien sûr, souvent elle ne le fait pas.
Dans ce cas, la question n'est pas de savoir s'il y a un modèle dans le marché, c'est par la nature même du marché
il doit y avoir des inefficacités qui sont soit limitées par la liquidité, soit limitées dans le temps.
En quoi l'inefficacité est-elle différente de la régularité ? En ce sens qu'il apparaît de manière aléatoire dans le temps et disparaît tout aussi aléatoirement une fois qu'il a épuisé ses liquidités.
eh bien, à mon avis, l'inefficacité est plus à court terme.
la régularité, c'est quelque chose comme des cycles de marché décennaux, il y a une baisse, il y a une hausse, ou des modèles saisonniers, et le reste, c'est de l'inefficacité.
L'intérêt est que vous n'avez pas besoin de vous prendre la tête avec R, Matlab, python et ainsi de suite. De toute façon, tout sera converti en C++, et ce processus est presque indépendant, le code dans R n'est pas un prototype pour C++. Les gens deviennent dépendants de divers RAD et se mordent ensuite les coudes, il leur faudra 2-3 ans pour se débarrasser de leurs mauvaises habitudes, si une personne se rend compte qu'elle s'est mise dans une impasse, mais souvent elle ne le fait pas.
Il y a exactement une ligne sur R dans l'article :
Parfois, mais rarement, on a envie de tirer dans Matlab ou R ;-) Un seul conseil : allez directement chez le médecin.
Je dois ajouter que cette phrase se réfère à la neuronique profonde et non à R en général. Le problème est que R est un interpréteur et donc la vitesse des calculs mathématiques est un peu plus lente que dans les langages de programmation compilés comme C++ ou Java.
Pour obtenir des performances élevées dans R, nous devons écrire la bibliothèque C++ avec une interface vers R, ce qui est fait dans la plupart des cas. Ou, logiquement, vous pourriez simplement créer un neuronkey directement en C++, sans R. Travailler avec des données en c++ est plus délicat qu'en R, mais apparemment cette approche est tout à fait acceptable.
En général, R en production est bon pour le traitement des données, vous n'avez pas besoin d'un médecin.
Créer une neuronique en R pur est toujours un mauvais ton.
Le fait est que vous n'avez pas besoin de vous lancer dans toutes sortes de "sucreries" sous la forme de R, Matlab, python et ainsi de suite. De toute façon, tout sera ensuite converti en C++, et ce processus est presque indépendant, le code en R n'est pas un prototype pour C++. Les gens s'accrochent à divers pop-up RAD et se mordent ensuite les coudes, il leur faudra 2-3 ans pour se débarrasser de leurs mauvaises habitudes, si une personne se rend compte qu'elle s'est engagée dans une impasse, bien sûr, souvent elle ne le fait pas.
99% des personnes sur ce forum sont des chercheurs qui n'ont pas une bonne stratégie de travail et qui la cherchent, ceux qui l'ont, ils sont plus susceptibles d'observer silencieusement ce fil ....
Donc si, en tant que chercheur, je voulais tester un réseau neuronal sur le marché, qu'est-ce qui est le mieux ? passer six mois à comprendre par moi-même et écrire le réseau en C++ et comprendre que ça ne marche pas, ou tester cette idée sur R "pops" en utilisant une solution déjà préparée et comprendre que ça ne marche pas non plus, mais ça prend moins de 30 minutes, c'est le plus de tous les R "pops", Je ne parle pas de la production - la production, c'est quand on sait exactement ce qu'on fait et qu'on a des TdR et ainsi de suite, et quand on fait de la recherche - c'est une méthode au feeling, on cherche juste, et si on écrit des solutions toutes faites pour chaque recherche, on va rater sa vie).
Je n'essaie pas de promouvoir R ou de dire que c'est le meilleur, vous pouvez écrire en Pascal si vous aimez ça, mais dans cette situation et dans ce contexte, lorsque vous faites des recherches sur le marché, R est la meilleure solution pour le moment. Mais quand vous aurez une production, vous devrez penser...
99% des personnes sur ce forum sont des chercheurs, ceux qui n'ont pas une bonne stratégie de travail et la cherchent, ceux qui l'ont, ils préfèrent regarder silencieusement ce fil....
Donc si, en tant que chercheur, je voulais tester un réseau neuronal sur le marché, qu'est-ce qui est le mieux ? passer six mois à comprendre par moi-même et écrire le réseau en C++ et comprendre que ça ne marche pas, ou tester cette idée sur R "pops" en utilisant une solution déjà préparée et comprendre que ça ne marche pas non plus, mais ça prend moins de 30 minutes, c'est le plus de tous les R "pops", Je ne parle pas de la production - la production, c'est quand on sait exactement ce qu'on fait et qu'on a des TdR et ainsi de suite, et quand on fait de la recherche - c'est une méthode au feeling, on cherche juste, et si on écrit des solutions toutes faites pour chaque recherche, on va rater sa vie).
Je n'essaie pas de faire la promotion de R ou de dire que c'est le meilleur, vous pouvez écrire en Pascal si vous aimez ça, mais dans cette situation et dans ce contexte, lorsque vous faites des recherches sur le marché, R est la meilleure solution pour le moment. Et quand il y aura une production, vous pouvez déjà y penser...
Cela dépend du type de recherche. Si vous effectuez des recherches pour votre travail de fin d'études, alors oui, il est beaucoup plus facile de prendre une fonction, de l'exécuter et d'obtenir un rapport standard avec de beaux graphiques, sans poser de questions.
Si les recherches des ingénieurs quant, dans les bureaux financiers, où ils prennent de l'argent du marché, pas seulement en raison des commissions, ou des technologies proches du marché, alors la situation est différente. En règle générale, dans les bons bureaux, il faut environ 5 ans pour construire l'infrastructure de négociation, où il y a 95 % de tous les outils nécessaires, qui sont emballés de manière pratique et que vous pouvez utiliser sans que cela soit beaucoup plus compliqué qu'en R, tout est transparent et disponible pour l'édition et la danse du tambourin. À ce niveau, un quant pense dans le système d'abstractions que lui fournit son infrastructure de négociation et plus ce système d'abstractions devient unique et non réductible à des parties communes. La plupart des idées de trading sont des variations de la structure des abstractions de haut niveau de l'infrastructure de trading, qui ne peuvent en principe pas être vérifiées dans R ou dans Matlab, car il ne s'agit pas d'alimenter MLP avec des stochastiques avec différentes fenêtres.
Parfois, je peux utiliser R(Matlab, maths) comme une sorte de calculatrice avancée lorsque j'ai besoin de dessiner une fonction exotique ou quelque chose d'étudiant similaire à essayer, mais c'est loin de chercher des stratégies de trading. Mais si vous écrivez du code de plus de 100 lignes en R avec une logique de stratégie, etc., vous prenez progressivement l'habitude de penser en termes de R , ce qui nuit ensuite fortement, car programmer avec des "cubes", etc. c 'est le danger. Les problèmes standard sont résolus rapidement, les problèmes complexes aboutissent souvent à une impasse, car ils ne peuvent pas être approchés par les outils disponibles ou nécessitent une danse du tambourin beaucoup plus alambiquée que dans les plus. Le codeur commence à penser comme un concepteur en pensant qu'il programme, puis il se contente de faire varier les paramètres d'un outil prêt à l'emploi et lorsque vous avez besoin de le programmer, il s'avère très peu convivial et peu pratique.
Cela dépend du type de recherche, s'il s'agit d'une recherche d'étudiant pour réussir un travail de semestre, alors oui, il est beaucoup plus facile de prendre une fonction sur l'étagère, de l'exécuter et d'obtenir un rapport standard en plus avec de beaux graphiques, il n'y a pas de questions.
Si les recherches des ingénieurs quant, dans les bureaux financiers, où ils prennent de l'argent du marché, pas seulement en raison des commissions, ou des technologies proches du marché, alors la situation est différente. En règle générale, dans les bons bureaux, il faut environ 5 ans pour construire l'infrastructure de négociation, où il y a 95% de tous les outils nécessaires, qui sont commodément emballés et que vous pouvez utiliser pas beaucoup plus compliqué que dans R, tout est transparent et disponible pour l'édition et la danse du tambourin. À ce niveau, un quant pense dans le système d'abstractions que lui fournit son infrastructure de négociation et plus ce système d'abstractions devient unique et non réductible à des parties communes. La plupart des idées de trading sont des variations de la structure des abstractions de haut niveau de l'infrastructure de trading, qui ne peuvent en principe pas être vérifiées dans R ou dans Matlab, car il ne s'agit pas d'alimenter MLP avec des stochastiques avec différentes fenêtres.
Parfois, je peux utiliser R(Matlab, maths) comme une sorte de calculatrice avancée lorsque j'ai besoin de dessiner une fonction exotique ou quelque chose d'étudiant similaire à essayer, mais c'est loin de chercher des stratégies de trading. Mais si vous écrivez du code de plus de 100 lignes en R avec une logique de stratégie, etc., vous prenez progressivement l'habitude de penser en termes de R , ce qui nuit ensuite fortement, car programmer avec des "cubes", etc. c 'est le danger. Les problèmes standard sont résolus rapidement, les problèmes complexes aboutissent souvent à une impasse, car ils ne peuvent pas être approchés par les outils disponibles ou nécessitent une danse du tambourin beaucoup plus alambiquée que dans les plus. Le codeur commence à penser comme un concepteur en pensant qu'il programme alors qu'il ne fait que modifier les paramètres d'outils prêts à l'emploi et, lorsqu'il faut le programmer, cela s'avère très peu convivial et peu pratique.
Ce n'est pas la première fois que ce forum impose un débat sur "Quelle est la meilleure langue ?".
Personnellement, je rappelle chaque fois que MT4/5 sont des outils de TRADING, pas des outils de programmation.
Qu'allez-vous programmer en C ou en R ? Qui a besoin de ce processus de toute façon ? Vous avez besoin d'argent, et il résulte du blocage de la prise de décision sur les postes. Il existe de nombreux outils prêts à l'emploi dans R à cet effet, et le problème n'est pas de développer ces outils, mais de les utiliser. Vous n'avez pas besoin de programmer quoi que ce soit en R - il y a beaucoup plus de choses qu'une seule personne peut maîtriser, n'est-il pas possible de comprendre une idée aussi simple ?
Et enfin, quelqu'un ici pourrait créer un code plus efficace en C.
Seules les personnes qui n'ont aucune idée de ce que l'on doit programmer peuvent faire de telles déclarations. S'ils parviennent à saisir l'objet de la programmation, ils découvriront qu'ils devront rivaliser avec les bibliothèques Fortran et C, les bibelots d'arithmétique matricielle et tout le reste dans le mode de chargement de tous les cœurs de l'ordinateur.
Les supporters de C ! Asseyez-vous et essayez de comprendre R, ne serait-ce qu'un peu, non pas avec R, mais avec les paquets R, par exemple ceux répertoriés dans le shell caret, qui comprend jusqu'à 200 paquets (plusieurs milliers de fonctions), pertinents pour le trading. Et alors, avec un peu de chance, vous perdrez le désir de démontrer publiquement votre ignorance.