Création d'un système de trading Python pour MT. - page 10
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
Je ne fais pas d'optimisation et toutes sortes d'ajustements et de sélections de paramètres. Une méthodologie différente, mais vous avez besoin d'un environnement comme 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 de 5 couches, soit environ 60 neurones, est de 3 à 5 ms.
Jusqu'à présent, je ne vois aucune confirmation réelle de l'alarmisme.
Non, je ne cherche en aucun cas à faire peur ou même à épaissir les couleurs, le fait même que vous écriviez vous-même toute l'infrastructure analytique est déjà - super !
Vous faites ce qu'il faut, je pense juste à voix haute à ce que j'ai affronté et sur lequel j'ai trébuché moi-même, si cela ne vous dérange pas, je ne me mettrai pas en travers de votre chemin)).
Non, je n'essaie pas de faire peur ou même de peindre par-dessus le marché, le simple fait que vous écriviez vous-même toute l'infrastructure analytique est super !
Vous vous débrouillez bien, je pense juste à voix haute à ce que j'ai affronté et sur lequel j'ai trébuché moi-même, si cela ne vous dérange pas que je m'écarte du chemin)).
Oui, c'est bien de communiquer. Des opinions différentes sont acceptables. Les adversaires sont toujours bons).
Oui, nous communiquons normalement. Des opinions différentes sont acceptables. Les adversaires sont toujours bons).
Ok. Alors que dire d'autre après avoir lu https://c.mql5.com/3/236/Public.zip ...
Je voudrais certainement de la structure et de la clarté, tant que le python travaille sur "diviser pour régner".
Au minimum, nous avons besoin d'une séparation claire en quelque chose comme des "interfaces" des modules d'alimentation en données, de leurs analyses/prévisions (d'alimentation en données), de l'exécution et de l'analyse des résultats des transactions, idéalement ces modules devraient être indépendants.
Abstraction faite des détails, il devrait y avoir au moins quatre objets complexes, les données, les modèles de ces données, la mise en œuvre (exécution) des modèles sur le marché et l'objet de l'estimation de cette activité.
Dans le cas le plus simple, le flux sera simplement un tableau de chandeliers, la seule subtilité de travailler avec un tel flux est d'avoir une protection fiable des modèles/exécution/modules d'estimation pour ne pas regarder dans le futur, le modèle le plus simple peut être n'importe quel indicateur, tel que RSI, stochastique, ou indicateur de réseau neuronal, soit modulé ou dans sa forme pure. Il s'agit d'une interprétation des prévisions en un signal de trading et de son exécution au ralenti/réel, par exemple en franchissant certains niveaux du module de prévision, etc. Et l'estimation est un "test", en fait le testeur n'est qu'un parcours à vide de toute la série de données, techniquement il est préférable de travailler avec l'état actuel du marché, les modules modèle/exécution/estimation comme dans la réalité, mais c'est beaucoup plus lent que d'émettre des signaux pour toute la série et ensuite de les exécuter séparément dans le testeur, mais il y a un grand danger d'espionner le futur et d'obtenir des résultats irréalistes.
PS : Maintenant, tous les gourous du Forex vont me lancer des piques, mais je dois dire que dans l'algotrading, les stops et les trailing stops sont une technologie nuisible, ils ne sont destinés qu'au trading manuel, épisodique, lorsque vous ouvrez une position pour avoir une chance et aller en pique-nique, et lorsque l'IA surveille continuellement le marché, alors agir en fonction de votre drawdown local n'a aucun sens, aucune dépendance du mouvement futur du marché et les décisions de l'IA ne devraient pas être basées sur cela.
OK. Eh bien, que dire de plus après avoir lu https://c.mql5.com/3/236/Public.zip ...
Vous attaquez Public en vain. C'est juste un modèle de stratégie simple avec une stratégie simple sur 2 MAs, trailing stop et testeur. Il doit avoir un code simple que tout le monde peut comprendre, et rien d'inutile. En outre, il est possible d'expérimenter des stratégies d'indicateurs. Et, si quelqu'un commence à modéliser des stratégies en Python, ce modèle peut être modifié et développé selon les besoins.
En fait, il a été conçu à l'origine comme un banc d'essai pour tester les différents modules du système et pour une publication ultérieure sur ce sujet. En tout cas, ce n'est pas du tout ce que vous pensez. En somme, ce n'est pas ce dont ça a l'air.
PS Au fait, qu'est-ce qui vous fait penser que votre testeur fonctionne correctement ? Le testeur est une chose délicate....
"techniquement, il est plus correct de travailler avec l'état actuel du marché, les modules de modèle/exécution/estimation comme dans la réalité, mais cela sera beaucoup plus lent que si vous émettez immédiatement des signaux pour toute la ligne et que vous les exécutez séparément dans le testeur, mais de cette façon il y a un grand danger d'espionner le futur et d'obtenir des résultats irréalistes.
C'est une question intéressante. C'est aussi intéressant parce que le forum produit déjà des légendes sur les miracles des tests). En fait, c'est pourquoi nous avons besoin de notre propre testeur, que nous pouvons entièrement contrôler.
Qu'est-ce qu'un testeur - il s'agit simplement d'une boucle qui doit informer la stratégie du nombre de bougies (ou du nombre de quelque chose d'autre, un tick, par exemple) avec lequel le testeur doit travailler. En outre, le testeur recueille des données sur l'état de la stratégie et les systématise d'une manière ou d'une autre dans les archives pour un traitement ultérieur par l'utilisateur. C'est tout. De quoi faut-il avoir peur ? Même si le testeur fait de gros efforts, il ne peut rien faire).
Il ne peut y avoir qu'une seule raison pour que les tests soient insidieux : la stratégie elle-même fonctionne avec d'autres types de données dans la vie réelle que dans les tests. Par exemple, avec des ticks au lieu de chandeliers. Et une vie amusante est garantie pour nous.
Tant que nous n'utilisons que l'ouverture ou la fermeture dans une stratégie et que nous n'utilisons que cela et rien d'autre dans le trading réel, nous ne sommes pas en danger (s'il n'y a pas d'erreurs évidentes, bien sûr). Mais dès que nous essayons d'utiliser OHLCV dans les essais, nous avons beaucoup de possibilités de nous tourner vers l'avenir. Premièrement, HL n'a pas d'horodatage, et deuxièmement, le prix d'une bougie peut se comporter comme il le souhaite, et toute hypothèse sur le comportement du prix ne peut qu'entraîner des distorsions dans le test.
Dans ce type d'analyse, nous sommes très limités dans ce que nous pouvons faire, et en fait nous ne pouvons utiliser les informations OHLCV qu'au début de la bougie suivante. Tout ce que nous pouvons faire sans risque est de fermer la transaction si le prix de la bougie actuelle passe en dessous du stop. Ce faisant, le stop ne doit bien sûr pas changer sur la barre actuelle.
ZS Je suppose que c'est le moment de parler des tests sur les tiques ). Je n'utilise pas les tics dans les tests, et je pense que l'analyse des tics est analogue à la tentative de calculer la trajectoire et les paramètres de mouvement d'un avion en mesurant les vibrations du fuselage et les fluctuations de la trajectoire.
Question intéressante. C'est aussi intéressant parce qu'il y a déjà des légendes sur les merveilles des tests dans ce forum). En fait, c'est pourquoi nous avons besoin de notre propre testeur, que nous pouvons entièrement contrôler.
Qu'est-ce qu'un testeur ? Il s'agit simplement d'une boucle qui doit informer la stratégie du nombre de bougies (ou du nombre de quelque chose d'autre, un tick, par exemple) avec lequel le testeur doit travailler. En outre, le testeur recueille des données sur l'état de la stratégie et les systématise d'une manière ou d'une autre dans les archives pour un traitement ultérieur par l'utilisateur. C'est tout. De quoi faut-il avoir peur ? Même si le testeur fait de gros efforts, il ne peut rien faire).
Il ne peut y avoir qu'une seule raison pour que les tests soient insidieux : la stratégie elle-même fonctionne avec d'autres types de données dans la vie réelle que dans les tests. Par exemple, avec des ticks au lieu de chandeliers. Et une vie amusante est garantie pour nous.
Tant que nous n'utilisons que l'ouverture ou la fermeture dans une stratégie et que nous n'utilisons que cela et rien d'autre dans le trading réel, nous ne sommes pas en danger (s'il n'y a pas d'erreurs évidentes, bien sûr). Mais dès que nous essayons d'utiliser OHLCV dans les essais, nous avons beaucoup de possibilités de nous tourner vers l'avenir. Premièrement, HL n'a pas d'horodatage, et deuxièmement, le prix d'une bougie peut se comporter comme il le souhaite, et toute hypothèse concernant le comportement du prix ne peut qu'entraîner des distorsions dans le test.
Dans ce type d'analyse, nous sommes très limités dans ce que nous pouvons faire, et en fait nous ne pouvons utiliser les informations OHLCV qu'au début de la bougie suivante. Tout ce que nous pouvons faire sans risque est de fermer la transaction si le prix de la bougie actuelle passe en dessous du stop. Ce faisant, le stop ne doit bien sûr pas changer sur la barre actuelle.
ZS Je suppose que c'est le moment de parler des tests sur les tiques ). Je n'utilise pas les tics dans les tests et je pense que l'analyse des tics est analogue à la tentative de calculer la trajectoire et les paramètres de mouvement d'un avion en mesurant les vibrations de son fuselage et les fluctuations de sa trajectoire.
Je suis d'accord avec beaucoup, le testeur a besoin de son propre, transparent et rapide, l'algorithme lui-même dans le cas simple (lorsque seulement les marchés sur le meilleur (bid, sask)) est d'environ 10 lignes de code, mais même en elle, vous pouvez vous tirer dans le pied. Eh bien, par exemple, si vous utilisez l'"exécution instantanée", c'est-à-dire, pour calculer la transaction au moment du signal, il se produit quand un homme a pris une bougie, par exemple, un Klos et a ensuite pris de cette série qui nibutuya différences mashah et puis à leur tour à nouveau sur klos (offre ou demande) ouvert / fermé une transaction au moment du signal, cette erreur donnera un résultat légèrement plus positif que le réel, il ne sera pas évident. D'autre part, si nous prenons la bougie suivante pour trader sur le signal précédent, le résultat sera nettement plus négatif que le réel. Classiquement, le signal est considéré sur les options, et le trade est basé sur les ralentissements de la même bougie, mais ce n'est pas non plus très bon, la pratique montre que les signaux sont meilleurs sur les options, et les transactions devraient être traitées par la moyenne (H+L+C)/3, bien que certaines personnes les mélangent plus intelligemment.
A propos, tout est très respectable et acceptable s'ils sont emballés dans des "tick candlesticks", c'est-à-dire des structures de chandeliers contenant les ticks qui se sont écoulés entre l'option et la clôture, l'indicateur peut être calculé par ticks et exécuté par ticks à l'intérieur d'un chandelier, bien que IMHO cela n'ait pas beaucoup de sens, les résultats seront assez similaires.
Mais avec le verre il y a plus de difficultés et d'ambiguïtés, heureusement cela ne concerne que ceux qui utilisent les sommes qui peuvent fortement assécher ce verre et donc c'est possible sans le verre.
Je suis d'accord avec beaucoup de choses, le testeur a besoin de son propre, transparent et rapide, l'algorithme lui-même dans un cas simple (lorsque seulement les marchés sur le meilleur (bid, ask)) est d'environ 10 lignes de code, mais même en elle, vous pouvez vous tirer dans le pied. Eh bien, par exemple, si vous utilisez l'"exécution instantanée", c'est-à-dire, pour calculer la transaction au moment du signal, il se produit quand un homme a pris une bougie, par exemple, un Klos et a ensuite pris de cette série qui nibutuya différences mashah et puis à leur tour à nouveau sur klos (offre ou demande) ouvert / fermé une transaction au moment du signal, cette erreur donnera un résultat légèrement plus positif que le réel, il ne sera pas évident. D'autre part, si nous prenons la bougie suivante pour trader sur le signal précédent, le résultat sera nettement plus négatif que le réel. Classiquement, le signal est considéré sur les options, et le trade est basé sur les ralentissements de la même bougie, mais ce n'est pas non plus très bon, la pratique montre que les signaux sont meilleurs sur les options, et les transactions devraient être traitées par la moyenne (H+L+C)/3, bien que certaines personnes les mélangent plus intelligemment.
A propos, tout est très respectable et acceptable s'ils sont emballés dans des "tick candlesticks", c'est-à-dire des structures de chandeliers contenant des ticks qui se sont écoulés entre l'option et la clôture, l'indicateur peut être calculé par ticks et exécuté par ticks à l'intérieur d'un chandelier, bien que IMHO cela n'ait pas beaucoup de sens, les résultats seront assez similaires.
Mais avec le verre il y a plus de difficultés et d'ambiguïtés, heureusement cela ne concerne que ceux qui utilisent les sommes qui peuvent fortement assécher ce verre et donc c'est possible sans le verre.
) En général, il s'agit d'une profonde modernisation de l'oscillateur stochastique classique, mais malgré des gènes communs, le descendant a très peu en commun avec l'oscillateur stochastique classique. Les mathématiques sont complètement différentes, mais la similitude extérieure est évidente.
Jusqu'à présent, l'indicateur a été implémenté uniquement en Python. Il a pour but de déterminer le moment de l'entrée dans la transaction et fait partie de son mécanisme de soutien. Vous pouvez déjà voir sur la figure qu'il le fait bien et à temps.
Bien entendu, l'indicateur n'est pas destiné à être utilisé seul, mais uniquement en symbiose avec d'autres méthodes et indicateurs.
Je pense que je devrais peut-être mettre l'indicateur dans MQL et le mettre dans le Marché.
Ceux qui ont lu le sujet De la théorie à la pratique savent déjà que mon système et celui d'A_K2 sont construits à peu près sur la même idéologie - le travail sur les canaux. La seule différence est que le mien a été construit il y a un an. J'ai déjà écrit auparavant que cette stratégie est maintenant implémentée et testée en Python, avec quelques changements mineurs, mais il n'y a aucun sens à la lancer - rien de nouveau n'est attendu.
Comme je n'avais pas d'idées particulières, j'ai développé toutes sortes d'indicateurs - l'un d'entre eux se trouve dans le post ci-dessus. J'en ai fait une dizaine. En conséquence, j'ai décidé de croiser le hérisson avec le hérisson : combiner le travail dans le canal avec le suivi de tendance dans un système cohérent. Je ne l'ai pas encore essayé dans son ensemble, mais j'en ai pratiqué certains éléments. Tout semble correspondre, mais j'ai encore quelques questions. Je ne peux pas dire ce qui sortira dans la pratique, peut-être rien. Attendons et voyons.