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
Entrez de manière à réaliser un bénéfice à droite du prix actuel)
Je n'ai pas demandé comment entrer.
Indice : j'ai eu un signal de vente déclenché il y a 3 heures. C'est faux ?
quantopian.com propose un testeur si vous êtes intéressé. Et ils financent également des stratégies réussies
Il s'attaque à la faible liquidité du marché russe. Si tu as 100 000 roubles ou 100 000 roubles, tu ne peux gagner de l'argent qu'avec de la bière, peut-être avec du poisson.
Et c'est le genre de personnes qui se promènent sur le forum en se disant fièrement qu'elles ont réussi en tant que traders )).
Il s'attaque au marché russe à faible liquidité. Si vous obtenez 100 000 roubles ou 100 000 roubles, vous ne gagnerez de l'argent que pour une bière, peut-être un poisson.
Et c'est ce genre de personnes qui se promènent sur ce forum en se disant fièrement qu'elles ont réussi en tant que traders )).
Andrei, je ne sais pas si nous allons gagner plus ... Vous êtes capable de bien plus que de négocier sur le marché des changes. Désolé si je vous dérange.
Permettez-moi de rappeler aux lecteurs le contenu de la série précédente.
Le but de ce sujet n'est pas de créer un système de trading (TS), mais de créer un TS spécifiquement en Python. Python a été choisi parce qu'il dispose de bibliothèques de traitement de données étendues, notamment pour l'apprentissage automatique, et qu'il serait très bon d'utiliser ces bibliothèques directement à partir du TS, au lieu de multiplier le système avec diverses interfaces interlangues. En outre, Python est un excellent environnement de simulation, dont les capacités ne sont pas inférieures à celles de MatLab, ce qui permettra idéalement de combiner la simulation du système et son environnement d'exécution. C'est-à-dire que l'étape de transfert du TS du modèle vers un autre langage de programmation est complètement exclue, et le modèle est directement utilisé dans le TS.
Pour le moment, nous avons mis en place : un modèle de stratégie, un testeur de stratégie, le tout testé sur une stratégie simple. Toutes les sources peuvent être téléchargées à partir du fichier joint dans l'un des messages précédents. Par ailleurs, j'ai réalisé un modèle de TS sur la base d'une ancienne stratégie de travail. Le modèle est testé sur les futures SBRF-12.17 et SBRF-06.18.
Testé également aujourd'hui sur les futures SBRF-09.18. Les résultats sont similaires à SBRF-06.18 et je pense qu'il est inutile de présenter des graphiques.
Maintenant, parlons des projets futurs.
1) Je voudrais mettre en œuvre le système pour les transactions réelles et virtuelles dès maintenant. La transaction virtuelle - c'est lorsque les demandes ne sont pas envoyées au courtier, et l'ouverture-fermeture des transactions est écrite dans le journal - dans notre cas, la table de la base de données SQLite. En général, cette étape dure environ un mois et est combinée avec le développement du système. La connexion avec le terminal à ce stade est prévue selon le schéma : terminal -> DLL -> base de données SQLite -> Python. Le protocole de communication est à peu près similaire à celui de l'échange de fichiers.
2. Le système est encore brut. L'ancien système, pris comme base, a été considérablement modifié, pratiquement seuls les principes de base demeurent - je ne vois pas l'intérêt de faire plusieurs fois la même chose. Jusqu'à présent, aucune manipulation n'a été effectuée sur les paramètres. En général, il y a encore beaucoup de sciage et de sciage à faire.
J'aimerais combiner ces deux étapes, mais pour l'instant je n'en ai pas la possibilité - je n'ai pas d'ordinateur libre. Et j'aimerais faire les deux. Je n'en ai même pas envie, mais j'aimerais le faire. Jusqu'à présent, mes priorités n'ont pas été choisies.
En tout cas, il y a beaucoup de travail à faire et je ne peux pas m'attendre à de nouveaux résultats dans un avenir proche.
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 bout de code ?
Et tout le temps et partout, dans chaque ligne plusieurs fois. Cette absurdité sera constamment répétée dans toutes les fonctions (méthodes) de toute classe.
L'idée m'est venue d'écrire un système de trading en Python,
...
Pourquoi pas en C++ ou C# ?
Le plus drôle, c'est qu'il peut même être écrit en MQL5, pourquoi cette couche de python qui rampe lentement ?Pourquoi pas en C++ ou C# ?
Le plus drôle, c'est qu'il peut même être écrit en MQL5, pourquoi cette couche de python qui rampe lentement ?En C++ et C#, je l'ai déjà).
Pour le reste, lisez soit les premiers messages du fil de discussion, soit les 3-4 messages précédents).
Je l'ai déjà en C++ et C#).
Pour le reste, lisez soit les premiers messages du fil de discussion, soit les 3-4 messages précédents).
Je pense que la plupart de ces systèmes sont écrits parce que l'auteur connaît bien tel ou tel outil.
Et dans l'ensemble, presque tout peut être écrit en MQL5.
Je pense que la plupart de ces systèmes sont écrits parce que l'auteur connaît bien tel ou tel outil.
Dans l'ensemble, presque tout peut être écrit en MQL5.
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 ont déjà été écrits, pratiqués et disponibles. Je ne veux pas les utiliser directement, au lieu de les réécrire ou de les adapter à MQL. C'est d'ailleurs le concept principal de la POO.