Suggestions pour EA (de perte à profit) - page 7
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
Non. Ce n'est pas vraiment ça, à ce stade. Cela PEUT être une perte de temps, de tester de l'achat à la vente, et vice versa, bien que cela ait donné des changements. Quand je dis, c'est ce que je voulais dire :
Trouver la meilleure solution dans le temps le plus court possible. Dans le même temps (très court), 5-10 minutes au plus, tester la logique par unité, de sorte que la logique PEUT être déterminée, disons. 99% bon ou 99% mauvais, c'est à peu près confirmé.
1) Vous prenez juste 1 logique principale, disons par ex :
et vous enlevez tout le reste, et vous faites ça :
c'est-à-dire par unité de logique - en testant à la fois l'achat et la vente, au MÊME moment. Donc, si vous souhaitez faire de l'optimisation avec cette logique maître, vous optimiserez simplement vos paramètres de base - sl, tp, lots, etc. uniquement. Ensuite, analysez les instances de leurs achats et ventes, jugez si cette logique unique peut faire l'affaire, dans les deux scénarios - si elle fait des entrées incorrectes ou correctes. Les deux. Puis passez à la logique suivante.
Au fur et à mesure que vous avancez, vous pouvez essayer des combinaisons... 1ère logique juste acheter, 2ème logique, juste vendre, ou les deux, etc. Je trouve que cette méthode est plus structurée et vous pouvez vraiment voir quelle logique précise est vraiment à l'origine du drawdown.
Je n'ai jamais testé un EA avec ces méthodes, alors soyez indulgent avec moi...
Ma question est la suivante : quels paramètres dois-je isoler pour me concentrer strictement sur le profit ?
Je n'ai jamais testé d'EA avec ces méthodes, alors soyez indulgent avec moi...
Ma question est la suivante : quels paramètres dois-je isoler pour me concentrer strictement sur le profit ?
Moi non plus. Je suis juste tombé sur cette idée totalement nouvelle en travaillant sur ce sujet. Je suis issu d'une formation plutôt technique, il m'a donc été facile de juger que certaines logiques sont complètement incorrectes/biaisées/fausses, sur les marchés.
Mais je me demandais : "Comment peut-on le prouver sur le testeur de stratégie, si c'est vraiment le cas ? Il doit bien y avoir un moyen de le faire", et c'est ainsi que je suis tombé sur cette méthode, par hasard.
Vous prenez simplement, dans ce cas, ces logiques de MA en condition de contrôle, une par une, disons par exemple, vous commencez avec M240close< MA 240. Vous testez les deux côtés - achat et vente, EN MÊME TEMPS. Maintenant, ce sont les cas :
1) Maintenant, mathématiquement, si cette logique est effectivement réalisable, le résultat devrait être quelque peu NEUTRE, puisqu'il couvre les deux côtés. Vous êtes d'accord ? Si elle s'avère rentable - alors vous pouvez conclure en regardant les résultats d'achat et de vente, cette logique fait très, très bien l'affaire, même si elle prend des coups de l'autre côté. Elle est donc très saine.
2) Maintenant, si le résultat est désastreux, alors vous pouvez conclure que la logique ENTIÈRE, c'est-à-dire la comparaison de la clôture à 240 avec la MA 240, est défectueuse à 100% contre toutes sortes de mouvements du marché. Vous devriez donc être convaincu que toute la logique devrait être retirée, remplacée complètement.
Laissez le reste - tp, sl, pour l'optimisation. C'est la correction de la logique, pièce par pièce, qui est la plus importante à ce stade.
Depuis que j'utilise cette approche, j'ai fait d'assez bons progrès avec les miens. Avant, je faisais les choses à peu près de la même manière que beaucoup, mais avec cette nouvelle méthode, je fais de sérieux progrès en très peu de temps...;-)
Moi non plus. Je suis juste tombé sur cette idée totalement nouvelle en travaillant sur ce sujet. Je viens d'une base plutôt technique, il m'a donc été facile de juger que certaines logiques sont complètement incorrectes/biaisées/fausses, sur les marchés.
Mais je me demandais : "Comment peut-on le prouver sur le testeur de stratégie, si c'est vraiment le cas ? J'ai donc découvert cette méthode par hasard.
Vous prenez simplement, dans ce cas, ces logiques MA en condition de vérification, une par une, disons par exemple, vous commencez avec M240close< MA 240. Vous testez les deux côtés - achat et vente, EN MÊME TEMPS. Maintenant, ce sont les cas :
1) Maintenant, mathématiquement, si cette logique est effectivement réalisable, le résultat devrait être quelque peu NEUTRE, puisqu'il couvre les deux côtés. Vous êtes d'accord ? Si elle s'avère rentable - alors vous pouvez conclure en regardant les résultats d'achat et de vente, que cette logique fait très, très bien l'affaire, même si elle prend des coups de l'autre côté. Elle est donc très solide.
2) Maintenant, si le résultat est désastreux, alors vous pouvez conclure que la logique ENTIÈRE, c'est-à-dire la comparaison de la clôture à 240 avec la MA 240, est défectueuse à 100% contre toutes sortes de mouvements du marché. Vous devriez donc être convaincu que toute la logique devrait être retirée, remplacée complètement.
Laissez le reste - tp, sl, pour l'optimisation. Il est plus important à ce stade de corriger la logique, morceau par morceau.
Depuis que j'utilise cette approche, j'ai fait d'assez bons progrès avec les miens. Avant, je faisais les choses à peu près de la même manière que beaucoup, mais avec cette nouvelle méthode, je fais de sérieux progrès en très peu de temps...;-)
Pourquoi ne pas simplement optimiser toutes les variables en même temps ? Cela peut prendre un certain temps pour effectuer le test d'optimisation, mais c'est pour cela que j'ai deux ordinateurs. Un pour les tests, un pour le développement.
En supposant que vous ayez un shell EA qui fonctionne correctement, c'est-à-dire SL, TP, Trailing SL, Increment, Stack, Risk, beaucoup d'heures pour trader, email, reporting, ouverture des ordres de fermeture, fonctionne sur plusieurs paires, etc. En supposant que tout cela fonctionne correctement, ce qui n'est pas une mince affaire, il vous reste alors la logique que vous utilisez pour entrer une transaction. Dans mon cas, j'ai Trade() qui renvoie 1, 0 ou -1. La logique de Trade() peut être le système que vous voulez y intégrer.
Je teste d'abord mon système logique en mode visuel, afin de m'assurer que la logique fonctionne correctement, par exemple que les stops sont placés au bon endroit, que l'entrée est au bon niveau et tout ce que le système demande. Une fois que c'est fait, cela prend généralement une heure ou plus pour tester, à moins que j'aie complètement perdu la tête. J'exécute ensuite l'ensemble de l'optimisation pour les plages de TP, la pile de SL, les heures de négociation et toute autre variable devant être testée dans la logique de négociation (Ma, modèles de barres, etc.).
Si vous exécutez toutes vos optimisations en même temps, vous aurez une meilleure idée du fonctionnement de la stratégie. Si vous voulez réduire le temps de test, exécutez une optimisation pendant une période plus courte, juste pour avoir un aperçu du système, disons 1-2 mois. Cela ne devrait pas prendre beaucoup de temps, 4 à 8 heures environ, si vous gardez vos gammes basses. Si cela semble prometteur, lancez un véritable backtest qui vous donnera une idée réelle de la façon dont le système fonctionne. Rien ne dit que vous ne pouvez pas arrêter un backtest après une centaine d'exécutions parce qu'il semble déjà être un perdant.
Dans mes tests, je considère le drawdown comme ma première statistique. Si mon EA perd plus de 12% avec un risque de 2%, je suis de toute façon de retour à la case départ. Si cela fonctionne, je regarde le pourcentage de gains et de pertes, et le ratio gains moyens/pertes moyennes. Je ne suis pas sûr que vous obtiendrez ces chiffres plus rapidement en procédant à votre manière. Si la plupart, 80-90%, de mes exécutions d'options ne réduisent pas le compte à zéro, alors vous avez une chance décente d'avoir un EA rentable. Je prends ensuite les exécutions à profit moyen, j'en fais la moyenne et je les réoptimise avec des plages plus petites afin d'obtenir mes paramètres pour un test ultérieur sur des données réelles. Cela peut prendre un mois. Je n'utiliserais pas d'argent réel tant que cela n'a pas été fait.
En tenant compte de tout ce qui précède, c'est juste la façon dont je fais le travail de développement, au moins avec les EA.
Je ne suis pas d'accord avec 1 ou 2.
1) Je ne pense pas que vous puissiez prouver ou même savoir si le système sera rentable à moins que vous n'exécutiez un parcours d'option dans le backtester avec toutes les variables possibles. Et si, SL, TP, Stack, la distance entre Stack, ou MoveStop fait de la stratégie un gagnant, Ce n'est pas vraiment un "et si", c'est un fait. Si vous testez votre façon de faire, vous avez toujours besoin d'un SP ou TP ou autre pour voir un gain ou une perte. Si vous avez un SL de 100 pip sur un graphique d'une minute, vous allez très probablement avoir un excellent système avec 85 -> 98% de gains. Je peux vous dire qu'il ne se comportera pas de la sorte lorsque vous l'exécuterez de manière optimale. Vous pouvez avoir un taux de victoire de 30% et un EA très rentable. Vous pouvez aussi avoir un taux de gain de 90% et le drawdown pourrait être de 70% et 3000 des 4000 runs d'optimisation vider le compte. Au bout du compte, vous allez de toute façon effectuer une exécution complète. Pourquoi ne pas le faire d'abord et coder un nouveau système en parallèle.
2) Cela peut tourner au désastre et vous lancez un système sans avoir effectué un test complet. C'est comme si vous jetiez à la poubelle un billet de loterie gagnant parce que vous venez de vérifier le numéro de la loterie et que vous savez que vous n'avez pas touché le jackpot. Vous aviez pourtant les cinq autres numéros et vous venez de jeter à la poubelle un billet gagnant de 250 000 euros, et maintenant un pigeon a un nid très cher.
En résumé, je pense que le codage du système est la partie du processus de développement qui prend le moins de temps. Les tests sont la partie la plus longue et la plus importante et je veux passer la plupart de mon temps dans la phase de test. J'ai aussi tendance à apprendre davantage de mes EA ratées, je sais que c'est ce que tout le monde dit, mais les échecs dans les tests ont tendance à aider à réduire les plages de paramètres pour les optimisations futures, ce qui rend les tests des EA les plus prometteuses plus rapides à la fin.
Juste mes deux centimes.
Pourquoi ne pas simplement optimiser toutes les variables en même temps ? Le test d'optimisation peut prendre un certain temps, mais c'est pourquoi j'ai deux ordinateurs. Un pour les tests, un pour le développement.
En supposant que vous ayez un shell EA qui fonctionne correctement, c'est-à-dire SL, TP, Trailing SL, Increment, Stack, Risk, beaucoup d'heures pour trader, email, reporting, ouverture des ordres de fermeture, fonctionne sur plusieurs paires, etc. En supposant que tout cela fonctionne correctement, ce qui n'est pas une mince affaire, il vous reste alors la logique que vous utilisez pour entrer une transaction. Dans mon cas, j'ai Trade() qui renvoie 1, 0 ou -1. La logique de Trade() peut être le système que vous voulez y intégrer.
Je teste d'abord mon système logique en mode visuel, afin de m'assurer que la logique fonctionne correctement, par exemple que les stops sont placés au bon endroit, que l'entrée est au bon niveau et tout ce que le système demande. Une fois que c'est fait, cela prend généralement une heure ou plus pour tester, à moins que j'aie complètement perdu la tête. J'exécute ensuite l'ensemble de l'optimisation pour les plages de TP, la pile de SL, les heures de négociation et toute autre variable devant être testée dans la logique de négociation (Ma, modèles de barres, etc.).
Si vous exécutez toutes vos optimisations en même temps, vous aurez une meilleure idée du fonctionnement de la stratégie. Si vous voulez réduire le temps de test, exécutez une optimisation pendant une période plus courte, juste pour avoir un aperçu du système, disons 1-2 mois. Cela ne devrait pas prendre beaucoup de temps, 4 à 8 heures environ, si vous gardez vos gammes basses. Si cela semble prometteur, lancez un véritable backtest qui vous donnera une idée réelle de la façon dont le système fonctionne. Rien ne dit que vous ne pouvez pas arrêter un backtest après une centaine d'exécutions parce qu'il semble déjà être un perdant.
Dans mes tests, je considère le drawdown comme ma première statistique. Si mon EA perd plus de 12% avec un risque de 2%, je suis de toute façon de retour à la case départ. Si cela fonctionne, je regarde le pourcentage de gains et de pertes, et le ratio gains moyens/pertes moyennes. Je ne suis pas sûr que vous obtiendrez ces chiffres plus rapidement en procédant à votre manière. Si la plupart, 80-90%, de mes exécutions d'options ne réduisent pas le compte à zéro, alors vous avez une chance décente d'avoir un EA rentable. Je prends ensuite les exécutions à profit moyen, j'en fais la moyenne et je les réoptimise avec des plages plus petites afin d'obtenir mes paramètres pour un test ultérieur sur des données réelles. Cela peut prendre un mois. Je n'utiliserais pas d'argent réel tant que cela n'a pas été fait.
En tenant compte de tout ce qui précède, c'est juste la façon dont je fais le travail de développement, au moins avec les EA.
Je ne suis pas d'accord avec 1 ou 2.
1) Je ne pense pas que vous puissiez prouver ou même savoir si le système sera rentable à moins que vous n'exécutiez un parcours d'option dans le backtester avec toutes les variables possibles. Et si, SL, TP, Stack, la distance entre Stack, ou MoveStop fait de la stratégie un gagnant, Ce n'est pas vraiment un "et si", c'est un fait. Si vous testez votre façon de faire, vous avez toujours besoin d'un SP ou TP ou autre pour voir un gain ou une perte. Si vous avez un SL de 100 pip sur un graphique d'une minute, vous allez très probablement avoir un excellent système avec 85 -> 98% de gains. Je peux vous dire qu'il ne se comportera pas de la sorte lorsque vous l'exécuterez de manière optimale. Vous pouvez avoir un taux de victoire de 30% et un EA très rentable. Vous pouvez aussi avoir un taux de gain de 90% et le drawdown pourrait être de 70% et 3000 des 4000 runs d'optimisation vider le compte. Au bout du compte, vous allez de toute façon effectuer une exécution complète. Pourquoi ne pas le faire d'abord et coder un nouveau système en parallèle.
2) Cela peut tourner au désastre et vous lancez un système sans avoir effectué un test complet. C'est comme si vous jetiez à la poubelle un billet de loterie gagnant parce que vous venez de vérifier le numéro de la loterie et que vous savez que vous n'avez pas touché le jackpot. Vous aviez pourtant les cinq autres numéros et vous venez de jeter à la poubelle un billet gagnant de 250 000 euros, et maintenant un pigeon a un nid très cher.
En résumé, je pense que le codage du système est la partie du processus de développement qui prend le moins de temps. Les tests sont la partie la plus longue et la plus importante et je veux passer la plupart de mon temps dans la phase de test. J'ai également tendance à apprendre davantage de mes EA ratées, je sais que c'est ce que tout le monde dit, mais les échecs dans les tests ont tendance à aider à réduire les plages de paramètres pour les optimisations futures, ce qui rend les tests des EA les plus prometteuses plus rapides à la fin.
Juste mes deux centimes.
Eh bien, mettons-nous d'accord sur notre désaccord.... et merci d'avoir écrit un post vraiment long. Peut-être que cet article fera l'affaire. optimisation = piège, vous pouvez y tomber. https://www.mql5.com/en/articles/1434
@c0d3 : Voici un conseil qui m'a été donné par d'excellents développeurs sur ce forum. N'utilisez jamais l'Optimiseur de stratégie (sauf pour un réglage fin). Le processus de développement idéal est le suivant : 1) Vous pensez qu' une stratégie a du sens. 2) Vous codez et testez la stratégie. 4) La stratégie s'avère rentable. 5) Vous utilisez Optimizer pour affiner la stratégie. 6) Vous tirez des enseignements des domaines où elle a échoué.
L'Optimizer est un #-cruncher qui fait que 1-pip Sl/Tp devient la différence entre gagner ou perdre. Optimiser les variables une par une ou toutes ensemble ne fait aucune différence, IMO. Voici mon saint-graal quand j'étais nouveau d'un mois. Si c'était aussi facile, je ne serais pas encore à la recherche de meilleures méthodes.
@c0d3 : Voici un conseil qui m'a été donné par d'excellents développeurs sur ce forum. N'utilisez jamais l'Optimiseur de stratégie (sauf pour un réglage fin). Le processus de développement idéal est le suivant : 1) Vous pensez qu' une stratégie a du sens. 2) Vous codez et testez la stratégie. 4) La stratégie s'avère rentable. 5) Vous utilisez Optimizer pour affiner la stratégie. 6) Vous tirez des enseignements des domaines où elle a échoué.
L'Optimizer est un #-cruncher qui fait que 1-pip Sl/Tp devient la différence entre gagner ou perdre. Optimiser les variables une par une ou toutes ensemble ne fait aucune différence, IMO. Voici mon saint-graal quand j'étais nouveau d'un mois. Si c'était aussi facile, je ne serais pas encore à la recherche de meilleures méthodes.
Dans l'ensemble, le trading est un jeu relativement "simple", si l'on considère ce fait. Personne, pas même les génies, ne négocie toute la journée comme le font certains robots - les bons, les exceptionnels ne prennent que 15-30 minutes, au maximum 1 heure pour entrer, sortir 70-100 pips et aller déjeuner. Cela semble assez difficile pour un robot ? Si vous pouvez faire cela toutes les semaines, ou tous les jours, et aimer le faire jusqu'à ce que vous soyez vieux comme cette vieille dame de YTE, c'est ce que j'appelle le Saint Graal, pas un robot qui doit être bricolé pour toujours.
Mais si vous voulez compliquer les choses avec un robot, préparez-vous à avoir à portée de main certaines connaissances sur ce qui fait vraiment fonctionner un programme informatique, en plus des marchés. Vous aurez peut-être besoin de compétences qui couvrent plusieurs domaines, pas seulement la programmation, mais aussi des sujets fondamentaux - la logique booléenne en est un, des connaissances en mathématiques et en ingénierie seront utiles, etc, etc. Ces compétences peuvent dépasser les capacités de certaines personnes.
Si vous voulez en savoir plus, ce que je peux partager, c'est que les tests et l'optimisation ne sont rien d'autre qu'un statisticien mécanique intelligent qui force les données à suivre une logique que VOUS lui avez donnée. Mais la vérité est que les marchés ne fonctionnent pas selon les lois statistiques ou VOTRE logique, si vous ne l'avez pas encore découvert.
J'ai des EAs commerciaux bien recommandés, qui ont donné des résultats de backtests agréables, mais qui m'ont quand même donné un énorme, énorme drawdown, surtout ces derniers mois. Maintenant, si vous avez vécu cela, vous comprendrez mieux ce que je veux dire. Il existe un Saint Graal, mais certainement pas un graal mécanique qui nécessite d'être bricolé juste pour s'adapter au moment. Et ses glorieux résultats de backtest.
Mon conseil est le suivant : prenez ce bricolage comme un hobby et prenez le trading SÉPARÉMENT. Si vous souhaitez combiner les deux, alors soyez prêt à faire votre propre sacrifice, à long terme.
99 % des personnes qui négocient sur le marché des changes perdent. Ce sont des traders qui ne sont pas des robots. Les robots ne sont pas mauvais, c'est un outil. Le robot est seulement aussi bon que l'argent et le temps que vous payez pour lui ;)
Eh bien, mettons-nous d'accord sur notre désaccord.... et merci d'avoir écrit un article très long. Peut-être que cet article fera l'affaire. optimisation = piège, vous pouvez y tomber. https://www.mql5.com/en/articles/1434
L'optimisation est un piège si vous la laissez vous piéger. J'utilise l'optimisation pour réaliser le plus grand nombre de transactions possible sur un certain nombre d'années. Pendant que je fais autre chose. Je ne mettrais pas un centime de mon argent dans un robot qui n'a pas été testé, rétro-testé et testé en amont. Le problème est le temps, combien de temps allez-vous attendre pour trader de l'argent réel. Je fais du trading depuis environ 5 ans, l'avantage d'un robot par rapport à un humain est le suivant : il fait ce que vous avez programmé. Il n'allume pas CNBC et n'écoute pas ce qu'un idiot pense, il n'attend pas une nouvelle publication, il ne devient pas nerveux et n'arrête pas une transaction prématurément parce qu'il a le sentiment que le marché va se retourner. Cela fonctionne également si vous n'êtes pas un trader à plein temps.
Si vous exécutez 12 000 simulations dans l'optimiseur et que 70 % de ces exécutions échouent, et que 10 % des exécutions vous rapportent 2000 % ou tout autre chiffre fou que les gens recherchent, alors vous avez pratiquement un système perdant et cela ne vaut pas la peine de passer du temps à le tester.
Si vous pensez que vous allez tester un système manuellement pendant un certain nombre d'années et le modifier après chaque tirage en changeant un paramètre à la fois, c'est plus insensé que d'utiliser l'optimiseur. Cependant, si vous exécutez disons 15 000 passes dans l'optimiseur et qu'aucune de ces passes n'est perdante, alors vous avez un système qui est prêt à être déposé sur un compte de démonstration pour des tests en amont pendant disons 4 semaines. C'est à ce moment-là que vous allez trouver les véritables bogues de codage.
Montrez-moi une personne qui trade 15-30 minutes par jour et accumule 100-150 pips puis va déjeuner, je vous montrerai une personne qui ne trade pas de l'argent réel. Le trading est un travail à temps plein, comme n'importe quel autre travail.
Si c'est un hobby, je ne vois pas pourquoi vous perdriez votre temps à faire ce type de codage. C'est assez facile techniquement et vous ne gagnerez pas autant d'argent que dans un emploi de développement normal. Je travaille sur un système dans mon travail de jour qui a près de 2 millions de lignes de code utilisant 4 langages et fonctionne sur des ordinateurs centraux, des PC, toutes les saveurs d'UNIX et la plupart des systèmes d'exploitation Linux.
À mon humble avis, l'article était intéressant. Cela ne veut pas dire que je crois chaque mot qu'il contient. C'est juste l'opinion de l'auteur. Ils ont probablement dû exécuter beaucoup d'optimisations pour arriver à la conclusion que l'optimazion est un piège. S'ils ont fait cela, alors comment l'article peut-il être correct puisque l'optimisation ne fonctionne pas.
@c0d3 : Voici un conseil qui m'a été donné par d'excellents développeurs sur ce forum. N'utilisez jamais l'Optimiseur de stratégie (sauf pour un réglage fin). Le processus de développement idéal est le suivant : 1) Vous pensez qu' une stratégie a du sens. 2) Vous codez et testez la stratégie. 4) La stratégie s'avère rentable. 5) Vous utilisez Optimizer pour affiner la stratégie. 6) Vous tirez des enseignements des domaines où elle a échoué.
L'Optimizer est un #-cruncher qui fait que 1-pip Sl/Tp devient la différence entre gagner ou perdre. Optimiser les variables une par une ou toutes ensemble ne fait aucune différence, IMO. Voici mon saint-graal quand j'étais nouveau d'un mois. Si c'était si facile, je ne serais pas encore à la recherche de meilleures méthodes.
Si vous pensez que vous allez tester un système manuellement pendant un certain nombre d'années et le modifier après chaque passage en changeant un paramètre à la fois, c'est plus insensé que d'utiliser l'optimiseur. Cependant, si vous exécutez disons 15 000 passes dans l'optimiseur et qu'aucune de ces passes n'est perdante, alors vous avez un système qui est prêt à être déposé sur un compte de démonstration pour des tests en amont pendant disons 4 semaines. C'est à ce moment-là que vous allez trouver les véritables bogues de codage.
C'est un bon point, sur le back-testing.