League of Trading Systems. Continuez à faire du bon travail. - page 70
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
Ici, parmi les TS qui ont nécessité une réoptimisation - il y en a un plutôt prometteur qui ira directement en première division.
TS 242250 - EMATrendSAR sur GBPJPY. L'historique de deux ans montre une qualité de 97%, l'estimation de la stabilité expérimentale est même de 47% (ce qui est beaucoup, seul un CT sur cent a une stabilité supérieure à 40%).
Le système a un facteur de profit de 2,2, la récupération est de 9,1 par an. Il est vrai que la file d'attente SL maximale est un peu longue - 5, et la baisse maximale du prix est de près de 8 mille points à trois chiffres. Mais voyons comment il va se comporter.
Je suis toujours en faveur d'une automatisation à 100%. Je ne comprends pas comment vous les réoptimisez, manuellement ? Ce n'est pas bon alors.
La moitié. Un script spécial sélectionne les systèmes à réoptimiser et prépare les fichiers d'installation. Ensuite, un autre script fait passer tous les systèmes par l'optimiseur. Le troisième script sélectionne les meilleures passes en fonction des résultats de l'optimisation, et prépare les fichiers contenant les procédures de réglage des systèmes. Ces textes sont transférés dans les classes de TC (je ne fais pas encore confiance à l'automate complet, et ici je contrôle entièrement le processus), puis le module exécutable est recompilé, mis à jour sur l'UPU, et le jour suivant le processus se répète.
La moitié. Un script spécial sélectionne les systèmes qui nécessitent une sur-optimisation et prépare les fichiers d'installation. Ensuite, un autre script fait passer tous les systèmes par l'optimiseur. Le troisième script sélectionne les meilleures passes en fonction des résultats de l'optimisation, et prépare les fichiers avec le texte des procédures de réglage du système. Ces textes sont transférés dans les classes de TC (je ne fais pas encore confiance à l'automate complet, et ici je contrôle entièrement le processus), puis le module exécutable est recompilé, mis à jour sur l'UPU, et le jour suivant le processus se répète.
1. destiné à sélectionner automatiquement les meilleurs systèmes et à trader sur eux. Dans le testeur, aussi.
2. nous effectuons des transactions virtuelles sur tous les systèmes XXX, évaluons les indicateurs, en sélectionnons quelques-uns pour les mettre en pratique, et leurs transactions sont ouvertes pour de vrai.
Si vous ne voulez pas vous embêter avec l'environnement virtuel (bien qu'il existe un fxsaber prêt à l'emploi), vous pouvez négocier 0,01 lot pour les statistiques et 1,00 pour les résultats.
Et il ne sera pas nécessaire de s'asseoir et de regarder la démo, tout deviendra clair immédiatement.
1. ici pour ces TS - peut-être. Il y a quelques moyennes de paramètres de TS, dont le choix, peut-être, n'est pas si facile à programmer, nous devons regarder chaque valeur "moyenne" du paramètre et à toutes les valeurs "moyennes" sélectionnées de paramètres sur l'histoire, et avec cette approche ne sera pas seulement "sélection automatique des meilleurs systèmes et le commerce sur eux", je pense plus fiable, que.
2. absolument correct. Tout à fait d'accord. Je vais moi-même être gêné par une telle approche. Le TS n'est pas encore prêt pour un tel test...
Depuis 2016... :-) pas tout écrit, bien qu'il n'y ait rien de particulièrement compliqué. Je n'ai pas le temps, le souci du pain quotidien et d'autres développements de CT ne me permettent pas de m'engager dans une créativité débridée dans cette direction.
Oh, Andrei.... Pourquoi vous marchez sur mon point sensible...
Le choix des meilleurs systèmes est la dernière question non résolue. Prendre "purement le meilleur" - il s'avère que c'est impossible. Vous prenez le système le plus performant et bang, il arrête de fonctionner. Bien qu'il semble avoir été testé et qu'il ait déjà montré plus d'une douzaine d'affaires réussies sur la démo... Mais, la durabilité, il s'avère qu'il n'y a pas... Quand je regarde des tableaux, je les compare, j'estime leur capacité de travail... Et du coup, l'installation des systèmes sur le réel, je l'ai jusqu'ici plus intuitive que formelle. Comment le coder ?
Et à propos de l'environnement virtuel - quel est l'intérêt d'utiliser un ordinateur puissant (je n'en ai qu'un), si je peux mettre tous les systèmes en démo, et, comme vous le suggérez à juste titre - "trader 0,01 lot pour les statistiques" ? C'est ce que je fais. J'ai un vieil ordinateur dans le grenier avec deux terminaux, et il gère les divisions moyenne et inférieure de la TC League. La division supérieure - se tient sur l'UPU (nous avons souvent des coupures de courant, je dois donc l'utiliser pour la division supérieure).
En fait, ma ligue de CT est un "environnement virtuel" où je teste constamment des systèmes en mode automatique. Tout est déjà installé ici, et la procédure de réinstallation en cas de paramètres de test est également standard et routinière.
La question reste précisément de sélectionner les plus durables. J'aime beaucoup le paramètre "qualité", j'ai réussi à le formaliser. Mais le paramètre "stabilité" est hors de ma portée. C'est ce sur quoi je travaille principalement en ce moment.
:-) Après le test et la sélection des paramètres en fonction de leurs valeurs - passez directement au système réel et commencez à vous battre. Vous les faites passer de la démo à la machine réelle, tard, si tard qu'il est temps de les retirer de la machine réelle et de réinitialiser les valeurs des paramètres...
Le temps réel représente 20 à 30 % du test, bien entendu, avec un échantillon de transactions et un temps de test raisonnables.
À mon avis, cette approche n'est pas correcte :"Jusqu'à cette date - il y a un test de deux ans, un an - en arrière, un an - en avant. Après cette date - TS est réglé sur démo, et le résultat des meilleurs systèmes de démo que je poste." de la page. 62.
Ce n'est pas la réponse à ma question.
Vous avez besoin d'un algorithme de sélection de système pour fonctionner dans le testeur. Et pour le tester. Pas besoin de démos du tout, une perte de temps.
C'est beau et profond... :-)
Je ne suis pas encore arrivé à cette page de la branche... parce que j'ai moi-même une approche différente du commerce...
Je le fais. Mais la fleur de pierre ne sort pas...
La suite est claire, et la Ligue peut très bien sélectionner les meilleurs CTs directement dans le testeur (ou avec l'aide de scripts et du testeur). Mais, tout d'abord, avant de fourrer l'algorithme de sélection dans le testeur - il faut l'inventer ! C'est-à-dire, au moins pour quelque chose à "attraper". Nous pouvons sélectionner les meilleurs afin de pouvoir vérifier dans le testeur si nous avons sélectionné des systèmes à l'aide de cet algorithme et s'ils fonctionnent de manière stable. Nous n'avons pas ça !
Ainsi, lorsque je préparerai la Ligue pour les projets partagés, je recommencerai à expérimenter cet algorithme de sélection.
Et à propos de "vous n'avez pas besoin d'une démo" - je ne suis pas d'accord. La démo est nécessaire pour voir la stabilité du système. Pour s'assurer que le système a fonctionné dans le testeur, et continue de fonctionner.
S'il vous plaît, ne comptez pas pour lever les os de la tombe. Jetez un coup d'œil aux liens de Robert Pardo. Il y explique tout sur l'optimisation et tout le reste.
https://www.mql5.com/ru/forum/131853/page4#comment_3359617
Ce qu'il faut, ce n'est pas une démo, mais un algorithme ou une approche (appelez-le comme vous voulez) pour sélectionner les valeurs moyennes des paramètres à partir d'ensembles donnés après le processus d'optimisation.
:-) Après le test et la sélection des paramètres, en fonction de leurs valeurs - immédiatement au réel et dans la bataille. Vous les faites passer de la démo au réel, tardivement, si tardivement qu'il est temps de les retirer du réel et de réopter les valeurs des paramètres...
Le temps réel représente 20 à 30 % du test, bien entendu, avec un échantillon de transactions et un temps de test raisonnables.
À mon avis, cette approche n'est pas correcte :"Jusqu'à cette date - il y a un test de deux ans, un an - en arrière, un an - en avant. Après cette date - TS est réglé sur démo, et le résultat des meilleurs systèmes de démo que je poste." de la page. 62.
Le compte de démonstration n'est plus nécessaire pour "des tests supplémentaires du TS". (bien que cela joue également un rôle). Le but principal du compte de démonstration est le "pool TS", l'existence constante des systèmes qui montrent un bon historique de trading.
En ce qui concerne le "temps de fonctionnement sur un compte réel à hauteur de 20% du test" - c'est une arme à double tranchant, car cela signifie qu'après le test de deux ans, le temps de fonctionnement du TS est de cinq mois maximum, et si nous ajoutons au test de deux ans un test de six mois sur la démo - alors nous avons un temps de fonctionnement du TS jusqu'à sept mois - ce qui est beaucoup plus long.
De manière réaliste, le compte de démonstration - ne change rien, enfin, je n'aurai pas de compte de démonstration, je vais juste le mettre sur le réel - et la question reste la même, qu'en est-il des centaines de TS de première division à mettre ?
S'il vous plaît, ne comptez pas pour ressusciter les os de la tombe. Consultez les liens de Robert Pardo. Il s'occupe de l'optimisation et de tout le reste.
https://www.mql5.com/ru/forum/131853/page4#comment_3359617
Vous n'avez pas besoin d'une démo, mais d'un algorithme ou d'une approche (appelez-le comme vous voulez) pour sélectionner les valeurs moyennes des paramètres parmi les ensembles proposés après le processus d'optimisation.
Qui pourrait prétendre qu'un algorithme ou une approche est nécessaire. Ici, j'essaie de trouver une solution (en me basant également sur les recommandations de Pardo). Et j'ai besoin d'une démo dans ce but précis, afin de ne pas avoir à réoptimiser un tas de systèmes à chaque fois, mais de prendre d'un coup ceux qui fonctionnent depuis un certain temps.
1. Le compte de démonstration n'est plus nécessaire pour une "vérification supplémentaire du TS" (bien que cela joue un rôle). (bien que cela joue également un rôle). L'objectif principal d'un compte de démonstration est le "pool TS", l'existence continue des systèmes qui présentent un bon historique de trading .
2. À propos du "temps de fonctionnement sur un compte réel de 20% du test" - c'est une arme à double tranchant, car cela signifie qu'après le test de deux ans, le temps de fonctionnement de TS est de cinq mois, et si un test de deux ans et il y a aussi un test de six mois sur la démo - nous avons déjà le temps de fonctionnement de TS jusqu'à sept mois - ce qui est beaucoup plus long.
3. Vraiment avoir un compte de démonstration - ne change rien, eh bien, ne sera pas avoir un compte de démonstration, je vais immédiatement mettre sur le réel - et la question reste la même, que des centaines de Top Division TS à mettre ?
1. je vois. si j'ai bien compris, vous avez tout chargé là et le total des fonds est en déficit.
2. ce n'est pas ça, le temps d'optimisation est de 2 ans. le temps de fonctionnement de l'UC est de 5 mois. Ensuite, ce n'est pas une demi-année de test de démonstration, puis - déjà négocié, tous les tests sont terminés.
"Et il y a un test semestriel sur la démo - alors nous avons déjà le temps de fonctionnement du TS jusqu'à sept mois - ce qui est sensiblement plus long." - Non, il faut recalibrer les paramètres pour que le marché soit à jour. Il vaut mieux qu'ils soient adaptatifs, par exemple à partir de la valeur du TAEG...
Р. Pardo n'est pas un gourou à lui seul, mais d'après d'autres sources, et même des discussions sur le forum mcl4, une telle approche est envisagée :
vous devez décider des valeurs des meilleurs paramètres du modèle si vous optimisez les paramètres à l'aide d'un algorithme génétique.
Ici, j'ai pris le meilleur modèle car il s'agit d'une énumération complète des valeurs des paramètres.
Par exemple, Optimisation - 4 ans. Essai avant 0,5 an. 0,5 année de 4 est 12,5%.
Ensuite, lorsque l'ALGORITHME spécifique sélectionne les paramètres du meilleur "modèle", la fin de l'analyse prospective d'un certain nombre d'optimisations, après l'optimisation suivante (extrême), comme dans votre cas, pendant 2 ans, ce n'est pas un test prospectif dans un trimestre, mais déjà le commerce, soit sur le réel ou démo, si les différences dans les systèmes tels que vous avez peu sur quel compte de commerce.
3. vous devez décider ... :-) (J'y pense - j'écrirai mon IMHO, un peu plus tard ...)