Création d'un système de trading Python pour MT. - page 9
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
Si vous pouvez tout écrire en MQL, vous n'avez vraiment besoin de rien d'autre.
Je ne peux pas et je ne veux même pas écrire et entrer dans les détails d'algorithmes qui sont déjà écrits, pratiqués et disponibles. Je ne veux pas les utiliser directement, au lieu de les réécrire ou de les adapter à leur application dans MQL. C'est d'ailleurs le concept principal de la POO.
Sans entrer dans les détails, la POO seule ne suffit pas, nous avons besoin de modèles de composants pour l'échange et l'interaction entre programmes, comme OLE->ActiveX->DCOM->.Net, sinon nous devrons toujours manœuvrer entre les langages et les bibliothèques.
Je suppose que Python, avec ses nombreuses bibliothèques, n'aura pas besoin de tout cela dans un avenir proche. À l'exception de la communication terminale, mais cette question a été résolue depuis longtemps et même de plusieurs manières.
Honnêtement, ce Python est ennuyeux, ainsi que ses classes. Voici un petit extrait de l'une de ces fonctions :
Comptez combien de fois le mot " self" est répété dans ce petit morceau de code ?
Et tout le temps et partout, dans chaque ligne plusieurs fois. Cette absurdité sera répétée dans toutes les fonctions (méthodes) de n'importe quelle classe, tout le temps.
yep... Oui, python n'est bon qu'en tant que "colle", pour des scripts de quelques lignes à quelques dizaines de lignes, alors il y a un avantage clair sur C++Java, mais il est plus coûteux d'implémenter une POO multi-tiers en python, même au niveau de la commodité, la vitesse de telles bibliothèques est hors de question. Python est amusant pour montrer des principes dans des présentations, etc. Il est très "propre" en apparence par rapport à la personnalisation, qui doit évidemment être écrite dans d'autres langages, mais pour écrire quelque chose de sérieux, avec des threads et une interface graphique en Python, c'est une véritable déception.
Le testeur propre est plus intéressant car vous pouvez avoir un contrôle total du processus, ce qui est absolument essentiel pour les tests. Et le testeur lui-même est une construction très simple.
Je ne vois pas l'intérêt de financer quoi que ce soit, puisque je ne le fais que pour moi.
Je ne le fais que pour moi. Le testeur n'a pas d'algorithme compliqué, mais il y a beaucoup d'endroits où je peux faire une erreur. Mais il va de soi que l'utilisation des développements de quelqu'un d'autre n'est pas moins risquée, au moins pour les mêmes raisons, et peut-être pour d'autres raisons liées aux spécificités de "qui en profite".
hum hum... Oui, python n'est bon qu'en tant que "colle", pour des scripts de quelques lignes à quelques dizaines de lignes, alors il y a un avantage clair sur C++/Java, mais il est coûteux de faire de la POO multicouche en python, même au niveau de la commodité, la vitesse de telles bibliothèques est hors de question. Python est amusant pour montrer les principes dans des présentations, etc. Il est très "propre" en apparence par rapport à la personnalisation, qui doit clairement être écrite dans d'autres langages, mais pour écrire quelque chose de sérieux, avec des threads et une interface graphique en Python, c'est une vraie souffrance.
Pourquoi "whew..." ? Tout va bien en Python, et la vitesse est bonne aussi. Même les boucles de 55k fonctionnent bien, dans l'avant-dernière version. En fait, les librairies de Python sont rapides, alors que Python lui-même sert surtout à relier des mots dans une phrase.
D'une manière générale, parler vite - lentement n'a aucun sens en soi. Si elle est rapide, à quoi sert-elle exactement ? Si c'est lent, c'est pareil.
C'est quoi ce "sifflement..." ? Tout y est bien en Python, et avec la vitesse aussi. Même les boucles de 55 km fonctionnent bien, dans l'avant-dernière version. En fait, les librairies de Python sont rapides, alors que Python lui-même sert surtout à relier des mots dans une phrase.
D'une manière générale, parler vite - lentement n'a aucun sens en soi. Si elle est rapide, à quoi sert-elle exactement ? Si elle est lente, de même.
55k c'est des miettes, il faut compter des milliards, et donc le testeur python natif ne fonctionnera pas, il faudra écrire et importer la libu sur les plus, et python n'est que pour appeler et configurer, car il peut être 100 fois plus lent.
et "ahem" était à propos de "self" et des 100500 méthodes et attributs __***__, IMHO ils rendent le code beaucoup plus compliqué que même avec les plus, et si nous parlons des threads, des événements et de l'interface graphique, tout n'est pas mieux qu'avec les plus, plutôt le contraire, tout ce "duck typing" et des trucs comme ça commencent à faire mal, vous devez garder beaucoup de choses à l'esprit, se souvenir de beaucoup de choses55k c'est des miettes, il faut compter les milliards, et donc un testeur python natif ne fonctionnera pas, il faudra écrire et importer la bibliothèque en plusses, et python seulement les appels et les configurations, parce que ça peut être 100 fois plus lent.
et "ahem" était à propos de "self" et des 100500 méthodes __***__, IMHO ils font du code beaucoup plus compliqué que même avec des plus, et si nous parlons de threads, d'événements et de GUI, tout n'est pas mieux qu'avec des plus, plutôt le contraire, tout ce "duck typing" et des trucs comme ça, au contraire, commence juste à faire mal, vous devez garder à l'esprit beaucoup de chosesJe ne sais pas pourquoi j'ai besoin de milliards)). Le testeur - Je n'ai pas à me plaindre, jusqu'à présent tout est rapide, 3 mois passent en un instant, et je n'ai pas besoin de plus).
Avec tout le reste, je pense que je suis d'accord, sur les plus est plus amusant à écrire. Mais on ne peut pas vraiment modéliser sur les points positifs. Il s'avère que : d'abord, nous modélisons quelque chose dans un logiciel, puis nous le portons sur les plus, nous écrivons toutes sortes d'interfaces avec les librairies - c'est une vraie galère.
Et en Python, tout en un seul paquet, et un environnement normal pour la modélisation + toutes les librairies nécessaires, généralement en C++. Pour la stratégie, c'est assez rapide - 15-30 ms n'est pas un délai pour moi. Éventuellement, vous pouvez réécrire les sections critiques en C, comme ils le font à la NASA. S'il y en a, bien sûr.
Et rien n'est parfait du tout).
Je ne sais pas pourquoi j'ai besoin de milliards.)) Testeur - Je n'ai pas à me plaindre, jusqu'à présent tout est rapide, 3 mois glissent en un instant, et je n'ai pas besoin de plus).
Avec tout le reste, je pense que je suis d'accord, sur les plus est plus amusant à écrire. Mais on ne peut pas vraiment modéliser sur les points positifs. Il s'avère que : d'abord nous modélisons quelque chose dans un logiciel, puis nous le portons sur les plus, nous écrivons toutes sortes d'interfaces avec les librairies - c'est une vraie galère.
Et en Python, tout en un, et un environnement de simulation normal + toutes les librairies nécessaires, généralement en C++. Pour la stratégie, c'est assez rapide - 15-30 ms n'est pas un délai pour moi. Éventuellement, vous pouvez réécrire les sections critiques en C, comme ils le font à la NASA. S'il y en a, bien sûr.
Et rien n'est parfait du tout).
Des milliards dans le contexte de l'optimisation lorsque des centaines voire des milliers de tests sont exécutés sur des centaines de milliers de barres de minutes. Nous ne sommes pas nos ennemis à attendre des heures pour récupérer quelques indices génétiques simples pour une année de minutes, cela devrait être fait en quelques secondes, alors qu'en Python cela prendrait beaucoup plus de temps, ainsi que sur des boîtes noires avec un ralentissement délibéré des calculs.
Et python en général est un outil très attrayant dans le bon contexte, même si, à mon avis, sa popularité actuelle est un phénomène transitoire, c'est un peu comme la mode des réseaux sociaux et des gadgets Apple, il y a un lien avec la brillance extérieure et le minimalisme sur des exemples très simples, et aussi les étudiants qui gonflent sa cote.
PS Au fait, pourquoi pensez-vous que votre testeur fonctionne correctement ? Le testeur est une chose délicate....
Des milliards dans le contexte de l'optimisation lorsque le test est exécuté des centaines voire des milliers de fois sur des centaines de milliers de barres de minutes. Nous ne sommes pas nos ennemis à attendre des heures pour quelques indices génétiques simples pour une année de minutes, cela devrait être fait en quelques secondes, mais en Python cela prendra beaucoup plus de temps, ainsi que sur des boîtes noires avec un ralentissement délibéré des calculs.
Je ne suis pas dans le domaine de l'optimisation et de toutes sortes de correspondances de paramètres. Ma méthodologie est différente, mais j'ai besoin d'un environnement similaire à MatLab, R, SciLab, etc. Python est tout aussi bon.
Je n'ai pas non plus besoin de 10^6 barres. Pour tout - environ 6, maximum 9 mois sur les minutes est suffisant. Maintenant le test est de 3 mois -2.5 m, bien que le système ne soit pas encore si compliqué.
Le plus long est d'apprendre le langage ML, mais il n'y a rien de mieux que Python, et ici, c'est seulement en tant que langage de script. Disons que la réponse d'un réseau neuronal formé de 5 couches, soit environ 60 neurones, est de 3 à 5 ms.
Jusqu'à présent, je ne vois aucune preuve réelle de cet alarmisme.