League of Trading Systems. Continuez à faire du bon travail. - page 66
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
Erm... Comment peut-on dire qu'il n'y a "pas d'exploitation de modèles réels" si la Ligue utilise exclusivement des modèles connus ?
Le favori du passé est ChnTrendSP - une rupture de canal avec des arrêts fixes - n'est-ce pas un modèle ?
Le favori actuel par équilibre - EMAFlatSP - entrée dans la contre-tendance, déterminée par le croisement du prix et de l'EMA avec des stops fixes - n'est-ce pas aussi un modèle ?
Selon vous, quel est le "vrai modèle" ?
Vous avez écrit vous-même que c'était une chose et que c'est devenu une autre, et tant que vous n'aurez pas compris qu'il faut changer un système pour un autre, vous vous retrouverez avec "0" bénéfice, et ça tourne à nouveau en rond.
...est réglé dans l'optimiseur. Dans ce cas, la quantité n'a pas d'importance dans toutes les combinaisons, les déchets entrent et sortent. Cela découle d'une logique triviale, vous n'avez même pas besoin d'être psychique ici.
L'optimisation est une question d'adaptation de toute façon. Mais, à mon avis, dans la Ligue - elle est bien moindre que celle de la plupart des experts de KodoBase.
Disons que, dans un système à canaux inversés, je n'ai qu'un seul paramètre de réglage - la période du canal.
De plus, mon optimisation est "multicouche". Cela signifie que s'il y a beaucoup de paramètres (disons, si nous définissons également le seuil de rentabilité), tout est d'abord optimisé sans seuil de rentabilité - c'est-à-dire que le système fonctionne même sans seuil de rentabilité. Ce n'est qu'ensuite que nous sélectionnons les paramètres du seuil de rentabilité, qui améliorent encore le système.
Si c'est une "poubelle", il m'est difficile de dire ce qui n'est pas une "poubelle".
Il n'y a pas de marches, donc vous ne pouvez pas le voir ! Jusqu'à présent, peu importe ce que j'essaie, je n'y arrive pas. Alors à quoi bon ouvrir des signaux et montrer quelque chose, s'il n'y a rien à montrer ?
"Pourquoi pas dans le testeur" - j'ai répondu, les tests sont effectués automatiquement, en utilisant des scripts, les paramètres trouvés sont immédiatement "notés" dans la Ligue, et plus loin - toutes les données de test sont supprimées. Au moment de la sur-optimisation - je peux "intercepter" les rapports de test - deux pièces de ces magiciens qui ont nécessité une sur-optimisation - j'ai posté. Tous les anciens sont partis. Aujourd'hui, d'ailleurs, un tas de systèmes sont morts - demain le script commencera à les réoptimiser, je peux poster des rapports de testeurs pour eux.
Ce n'est pas la réponse à ma question.
J'ai besoin d'un algorithme pour sélectionner les systèmes à travailler dans le testeur. Et pour le tester. Pas besoin de démos du tout, une perte de temps.
L'optimisation est de toute façon une question d'adaptation. Mais, à mon avis, dans la Ligue - il est beaucoup moins que dans la plupart des experts KodoBase.
Par exemple, dans un système à canaux inversés, je n'ai qu'un seul paramètre de réglage : la période du canal.
De plus, mon optimisation est "multicouche". Cela signifie que s'il y a beaucoup de paramètres (disons, si nous définissons également le seuil de rentabilité), tout est d'abord optimisé sans seuil de rentabilité - c'est-à-dire que le système fonctionne même sans seuil de rentabilité. Et ce n'est qu'ensuite que nous sélectionnons les paramètres d'équilibre qui améliorent encore le système.
Si c'est "n'importe quoi", il m'est difficile de dire ce qui n'est "pas n'importe quoi".
On parle d'optimisation lorsqu'il existe un modèle fondamental, mais que les paramètres du TS doivent être améliorés pour qu'il fonctionne mieux. Et lorsque le TS lui-même ne commence à fonctionner qu'après l'optimisation, alors qu'il ne fonctionnait pas avant, c'est une mauvaise optimisation.
En gros, il n'y a pas de problème si vous ne le réglez pas et il fonctionnera toujours, mais vous pouvez le régler en option. Et de tels systèmes sont très peu nombreux dans la nature, donc la question raisonnable est de savoir si vous devez transporter tout le reste des déchets et attendre qu'ils se déclenchent.
...
Si c'est "nul", il m'est difficile de dire ce qui n'est pas "nul".
George, pensons logiquement.
Je vais essayer d'être constructif. Techniquement, cependant, c'est difficile.
Au début, je voulais vous conseiller de réfléchir aux stratégies utilisées, mais je me suis ensuite rendu compte que l'essence de l'expérience de la Ligue est tout le contraire.
A savoir :
Le but principal de l'expérience : Trouver un algorithme pour sélectionner les systèmes pour chaque période de la dynamique du marché.
Ce faisant, il y a une condition : les systèmes peuvent être ce que vous voulez. Il n'est pas nécessaire de réfléchir sérieusement à l'essence. Le critère principal - le profit dans le testeur.
Cette expérience est certainement intéressante. Bien que ses résultats ne coïncident pas avec les désirs de George. Il aimerait trouver un algorithme pour sélectionner des systèmes aléatoires dans une dynamique aléatoire, mais l'algorithme est introuvable...
Parce que cet algorithme est le Graal...
Le résultat réel prouve que le système lui-même, et les méthodes de son application, doivent avoir un sens.
Je suggère à George de créer un robot unique et significatif, capable de s'adapter à la dynamique actuelle du marché. Mais l'adaptation, non pas par l'optimisation, et non pas par la MO, mais par une évaluation significative de ce qui se passe. (La tâche est plus proche de la création d'une IA).
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.
Je le fais. Mais la fleur de pierre ne sort pas...
C'est clair d'ici, et la Ligue peut très bien sélectionner le meilleur TS 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 voir 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 !
Lorsque je préparerai la Ligue pour les projets partagés, je commencerai à nouveau des expériences avec cet algorithme de sélection.
Et à propos de "nous n'avons pas besoin d'une démo" - je ne suis pas d'accord. Nous avons besoin de la démo pour voir si le système est stable. Pour s'assurer que le système a fonctionné dans le testeur, et continue de fonctionner.
On parle d'optimisation lorsqu'il existe déjà un modèle fondamental, mais que les paramètres du TS doivent être ajustés pour qu'il fonctionne mieux. Et lorsque le TS lui-même ne commence à fonctionner qu'après l'optimisation, alors qu'il ne fonctionnait pas avant, il s'agit d'une mauvaise optimisation.
En gros, il n'y a pas de problème si vous ne le réglez pas et il fonctionnera toujours, mais vous pouvez le régler en option. Et de tels systèmes sont très peu nombreux dans la nature, donc la question raisonnable est de savoir si vous devez transporter tout le reste des déchets et attendre qu'ils se déclenchent.
Je suis tout à fait d'accord avec la première affirmation. C'est ce que je fais.
La question qui se pose est de savoir s'il est nécessaire ou non de trier les déchets. En gros, est-ce qu'il y a besoin d'une division intermédiaire, ou plus encore, d'une division inférieure ? Ouais, il n'y a aucun moyen de le savoir. Il est clair que pour l'utilisation et l'amélioration - seulement les CT de la division supérieure, avec la qualité du commerce pas moins de 80% sont considérés, et tout ce qui est pire - c'est plus de "lest".
Cela ne prend pas mon temps - seulement le temps du processeur. Chaque matin, j'exécute simplement un script qui génère une liste des systèmes à réoptimiser, puis les réoptimise. Après cela, il me suffit de recompiler le module EX et de le mettre à jour sur l'UPU. Qu'il n'y ait qu'une seule division supérieure ou les trois, cela ne fait absolument aucune différence - cela me demande à peu près le même effort corporel. Ainsi, jusqu'à présent, les 672 CT fonctionnent sur la démo. Si la complexité du support - alors cette question serait un problème, et, bien sûr, je ne m'embêterais pas avec les "CT poubelles".
Erm... Comment peut-on dire qu'il n'y a "pas d'exploitation de modèles réels" si la Ligue utilise exclusivement des modèles connus ?
Le favori du passé est ChnTrendSP - une rupture de canal avec des arrêts fixes - n'est-ce pas un modèle ?
Le favori actuel de la balance - EMAFlatSP - entrée dans la contre-tendance, déterminée par le croisement du prix et de l'EMA avec des stops fixes - n'est-ce pas un modèle ?
Selon vous, quel est le "vrai modèle" ?
George, salut. Vous avez beaucoup critiqué mes idées, mais en lisant votre fil, je constate que vos idées sont tout autant critiquées. Apparemment, c'est la tradition du forum.
Permettez-moi d'exprimer mon opinion sur l'essence de la Ligue.
Malheureusement, l'idée de la Ligue, sous cette forme, est un discrédit involontaire du commerce. Votre approche prive l'essence du commerce. Pourquoi ?
Parce que :
En un mot, vous créez vous-même des déchets, puis vous créez l'illusion de leur valeur (éventuelle) par l'optimisation, et enfin vous les jetez, en étant convaincu à chaque fois que ce sont des DÉCHETS.
Vous finissez par discréditer involontairement le trading, en convainquant tout le monde de l'inutilité d'essayer de créer des systèmes de trading.
Je sais que vous le faites sans le vouloir, mais dans votre subconscient, ça marche comme ça.
1. Je ne suis pas d'accord. Toutes les TS de la Ligue sont des techniques assez bien connues et largement utilisées. Différents symboles fonctionnent pour l'un ou l'autre. Ici, je serais plutôt d'accord avec Maxim pour dire que "seule la Haute Division est nécessaire, le reste est de la camelote". C'est comme ça. En haute division, les systèmes qui correspondent au comportement des symboles fonctionnent. Et ceux qui ne le font pas - vont dans la division moyenne et inférieure.
C'est juste que j'ai remarqué plus d'une fois que le même système fonctionne avec succès en Haute Division pendant un certain temps, puis tout d'un coup, il cesse de fonctionner. L'exemple brillant que j'ai déjà mentionné - la rupture du canal sur GBPUSD - le système a très bien fonctionné pendant toute une demi-année. Et puis - bang... et quelque chose a changé, maintenant il ne peut même pas entrer dans le top du classement. Ici, les divisions moyenne et inférieure sont intéressantes pour moi, précisément pour observer les "anciens favoris".
2. La qualité n'est pas du tout atteinte par l'optimisation. Je suis à nouveau d'accord avec Maxim sur ce point - le système devrait déjà montrer au moins quelques résultats sans aucune optimisation, et l'optimisation ne fait que l'améliorer. La qualité est obtenue grâce à ces mêmes "pièges à motifs". Pour chaque symbole, j'exécute TOUTES les variantes. Afin de voir lequel fonctionne. Et vous devez continuer à l'utiliser, l'améliorer et le rendre encore meilleur.
3. Tout va bien. Mais si le système ne se conforme pas au comportement du symbole, il ne s'y conformera pas, quelle que soit la façon dont vous l'optimisez. Je mentionne ici les mots de Maxim pour la troisième fois - le premier des rapports affichés était une foutaise. En d'autres termes, même la meilleure variante du système est un commerce assez médiocre. L'essence d'un tel système consiste simplement à voir quelles sont les techniques qui ne fonctionnent PAS.