L'apprentissage automatique dans la négociation : théorie, modèles, pratique et algo-trading - page 1196
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
Magnifique !
Question en tant que spécialiste de Python, donnez-moi quelque chose en Python à expérimenter, j'ai presque réussi à maîtriser Sharpe, il se lie avec MT5 sans aucun problème, C# et Python sont censés le supporter, alors je peux passer à Python ;)
Python n'a RIEN à voir avec notre problème. Python est un amas de tout et n'importe quoi qui peut nous être utile, un sous-plateau de ploucs avec des versions obscures qui ne sont pas compatibles de haut en bas. Le support de Python est purement rustique, sur des passionnés. Les rubriques de paquets acceptables en Python n'existent pas en tant que telles. Tout ce qu'on peut trouver en Python est une recherche dans les forums, par des passionnés.
C'est particulièrement clair lorsque l'on compare Python à R. R est notre système, avec un excellent appareil de référence et notre rubricator. Il n'y a aucun problème pour trouver les outils dont vous avez besoin. Chaque paquet est bien documenté : descriptions des appels de fonctions, liens vers les algorithmes qui implémentent ces fonctions, exemples, liens vers des articles relatifs au paquet. R peut être utilisé comme un manuel pour tout problème. Et tout le matériel est absolument concret, soutenu par le code correspondant.
Python n'a pas et ne peut pas avoir d'avantage sur R, car tout ce qui est intéressant pour nous est écrit en Cp, alors que Python ou R sont les shells de ces paquets. Parfois, Python est en avance sur le nouveau paquet, en raison de l'absence totale d'exigences de conception pour les paquets et du support qui en découle. Tout ce qui apparaît sur les miroirs R est modéré et les déchets sont filtrés.
Le revers de la médaille de R est Srr, R lui-même est écrit en Srr, avec une interface parfaitement documentée entre R et Srr. Il vous est donc toujours possible d'abandonner le shell R et d'utiliser directement l'outil lui-même, écrit en Srr, à partir de programmes sur MCL.
Une dernière chose. Pour autant que je sache, il n'existe toujours pas de passerelle entre Python et MCL. Mais un tel pont entre R et les deux MCL existe depuis de nombreuses années, il est librement disponible dans kodobase, et il n'y a pas de plaintes - tout fonctionne de manière stable, le testeur fonctionne et je n'ai pas encore vu de plaintes concernant la vitesse : les données sont envoyées en mémoire.
Python n'a absolument RIEN à voir avec nos problèmes. Python est un amas de tout et n'importe quoi qui nous est utile, un sous-plateau de ploucs avec des versions incompréhensibles qui ne sont pas compatibles de haut en bas. Le support de Python est purement rustique, sur des passionnés. Les rubriques de paquets acceptables en Python n'existent pas en tant que telles. Tout ce qu'on peut trouver en Python est une recherche dans les forums, par des passionnés.
C'est particulièrement clair lorsque l'on compare Python à R. R est notre système, avec un excellent appareil de référence et notre rubricator. Il n'y a aucun problème pour trouver les outils dont vous avez besoin. Chaque paquet est bien documenté : descriptions des appels de fonctions, liens vers les algorithmes qui implémentent ces fonctions, exemples, liens vers des articles relatifs au paquet. R peut être utilisé comme un manuel pour tout problème. Et tout le matériel est absolument concret, soutenu par le code correspondant.
Python n'a pas et ne peut pas avoir d'avantage sur R parce que tout ce qui est intéressant pour nous est écrit en Cp, alors que Python ou R sont les coquilles de ces paquets. Parfois, Python bat l'apparition d'un nouveau paquet en raison de l'absence totale d'exigences de conception sur les paquets et le support qui en découle. Tout ce qui apparaît sur les miroirs R est modéré et les déchets sont filtrés.
Le revers de la médaille de R est Srr, R lui-même est écrit en Srr, avec une interface parfaitement documentée entre R et Srr. Il vous est donc toujours possible d'abandonner le shell R et d'utiliser directement l'outil lui-même, écrit en Srr, à partir de programmes sur MCL.
Une dernière chose. Pour autant que je sache, il n'existe toujours pas de passerelle entre Python et MCL. Mais un tel pont entre R et les deux MCL existe depuis de nombreuses années, il est disponible gratuitement dans kodobase et il n'y a pas de plaintes - tout est stable, le testeur fonctionne et je n'ai pas encore vu de plaintes concernant la vitesse : les données sont envoyées en mémoire.
Je préfère aussi R, mais je crois que l'avenir dans notre domaine est en python. Vous pouvez y construire un système complet en boucle fermée, de l'analyse au trading. Un exemple est le quantopian. Ça ne marchera pas pour R.
Je préfère R également, mais je crois que l'avenir dans notre domaine réside dans python. Il peut être utilisé pour créer un système entièrement en boucle fermée, de l'analyse au trading. Un exemple est le quantopian. Ça ne marchera pas dans R.
Pourquoi ça ne marche pas ? Il me semble que c'est déjà le cas depuis de nombreuses années. Il existe son propre terminal IBrokers qui dispose d'une API vers le même courtier que quantopian.
Une fois encore, Python est le même shell que R. Seul R est un développement sérieux, tandis que Python est un outil pratique, beaucoup d'utilisateurs qui ne sont pas essentiels pour nous et créent du bruit.
Le revers de la médaille de R est Srr, R lui-même est écrit en Srr, avec une interface parfaitement documentée entre R et Srr. Il vous est donc toujours possible d'abandonner le shell en R et d'utiliser directement l'outil lui-même, écrit en Srr, à partir de programmes en MKL.
C'est probablement pour cela que la passerelle pour R est écrite en pascal.
Vous feriez un bon vendeur, félicitations.
Vous feriez un bon vendeur, félicitations.
Citez au moins un logiciel d'apprentissage automatique largement connu et populaire (pas pour vous, mais pour la communauté mondiale) en R.
Y en a-t-il d'autres ? Pas en R ? Il y en a près de 200 dans le seul shell caret et pas tous, comme keras lui-même. Voulez-vous que je recueille des statistiques sur leur utilisation dans la communauté mondiale ?
Ce ne sont que des paroles en l'air, comme toute conversation sur le choix d'un langage de programmation. Je ne suis pas un fan des podlouches. Et pour moi, c'est le critère décisif. Chacun son truc.
Y en a-t-il d'autres ? Pas sur R ? Il y en a près de 200 dans le seul shell caret et pas tous, comme keras lui-même. Voulez-vous que je recueille des statistiques sur leur utilisation dans la communauté mondiale ?
Ce ne sont que des paroles en l'air, comme toute conversation sur le choix d'un langage de programmation. Je ne suis pas un fan des podlouches. Et pour moi, c'est le critère décisif. Et là, à chacun son métier.
Eh bien, je vois qu'ils commencent à ajouter R, comme TFlow et MXnet, avant c'était seulement python.
Cela doit être la raison pour laquelle la passerelle pour R est écrite en Pascal.
Quelle différence cela fait-il de savoir en quoi il est écrit ?
La passerelle a été écrite il y a 10 ans, à l'époque où elle était utilisée pour enseigner la programmation aux étudiants. Puis Pascal est mort subitement.
Mais le principal avantage du pont - sa primitivité, il ne nécessite pas de temps pour le maîtriser.
J'ai même ouvert une succursale ici, je me suis agité pour écrire quelque chose de plus décent, même en formulant les TdR, mais personne n'en veut, donc ce que nous avons, nous l'avons. Python n'a pas cela non plus.
Ok, je vois qu'ils ont commencé à ajouter R, comme TFlow et MXnet, avant il n'y avait que python.
J'ai écrit sur le forum : je ne vois aucun avantage à remplacer un paquet par un autre. Tout le problème réside dans les prédicteurs et leur capacité de prédiction pour un enseignant particulier. Si ce problème est résolu, vous pouvez, au prix du paquet, vous débarrasser de quelques pour cent de l'erreur, mais cela n'en vaut pas la peine.