League of Trading Systems. Continuez à faire du bon travail. - page 9
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
Ensuite, des experts testeurs spéciaux sont lancés, qui sélectionnent les meilleures passes en fonction des résultats de l'optimisation, et forment directement un texte de fonctions pour chaque CT, qu'il suffit de transférer dans le code expert, de lancer tout pour la recompilation et de continuer le travail.
C'est-à-dire que vous avez créé un générateur de code, et non pas quelque chose de primitif, basé sur un schéma fonctionnel dessiné par un homme, comme il y en a beaucoup, mais automatique, qui forme lui-même la logique du programme ; j'y travaille aussi et je pense que c'est une tendance prometteuse dans le développement de l'intelligence artificielle.
Je pense qu'il s'agit également de l'élément clé de votre tâche de création de systèmes de trading et je vous suggère de vous concentrer sur cet élément. Montrez-moi des exemples de vos propres systèmes générés automatiquement et je suis prêt à vous montrer les miens.
En d'autres termes, vous avez créé un générateur de code et non pas quelque chose de primitif, basé sur un schéma fonctionnel dessiné par un homme, comme il y en a beaucoup, mais automatique, qui forme la logique du programme par lui-même. J'y travaille aussi et je considère cette direction comme une tendance prometteuse dans le développement de l'intelligence artificielle.
Bien.
Mais la réalité s'est avérée plus simple. J'ai commencé avec cette logique de programme très variable, j'ai construit des blocs pour former le texte du programme, j'ai essayé d'utiliser des réseaux neuronaux... Mais on m'a assuré qu'il n'y avait pas de profit particulier à en tirer. Par conséquent, dans le générateur de code, je change simplement les blocs prêts à l'emploi (différents pour les différents TS), et je "marque" les valeurs des paramètres. Il s'est avéré que ce système n'est pas du tout pire.
Le générateur de code offre de nombreuses possibilités, mais je crains que nous n'y arrivions jamais.
Bien.
Mais la réalité s'est avérée plus simple. J'ai commencé avec cette logique de programme très variable, j'ai construit des blocs pour former le texte du programme, j'ai essayé d'utiliser des réseaux neuronaux... Mais on m'a assuré qu'il n'y avait pas de profit particulier à en tirer. Par conséquent, dans le générateur de code, je change simplement les blocs prêts à l'emploi (différents pour les différents TS), et je "marque" les valeurs des paramètres. Ce système, comme il s'est avéré, n'est en rien pire.
Le générateur de code offre de nombreuses possibilités, mais je crains que nous ne les abordions pas.
Cela rappelle un peu la vieille blague sur la fabrication d'un avion à partir de dessins de locomotives à vapeur avec des modifications ultérieures à l'aide d'un fichier :)
Le passage d'un bloc de code à un autre n'est qu'une imitation grossière et échelonnée de la création d'une nouvelle TS, et il n'est pas certain qu'en ajustant les variables dans l'optimiseur, il sera possible de lisser ces étapes.
Cela rappelle une vieille anecdote sur la fabrication d'un avion à partir de dessins de locomotives à vapeur, avec des ajustements ultérieurs à la lime :)
C'est vrai. Mais l'expérience montre que c'est la commutation grossière qui est la plus judicieuse.
Les entrées en sont un bon exemple. Après tout, il existe un très grand nombre d'entrées qui peuvent être inventées. Cependant, tous gravitent autour de deux variantes - entrer sur la barre glissante et entrer sur la limite du canal. C'est ça ! Peu importe ce que vous pouvez imaginer, la différence entre ces deux options sera exprimée en unités de pourcentage. Quel est donc le sens de prendre des centaines de variantes d'entrées si elles ne diffèrent pas beaucoup de ces deux qui diffèrent fortement l'une de l'autre ?
Et il en va de même pour les filtres et l'accompagnement...
Il ne sert à rien de "lisser le code". Un "changement d'étape" s'avère plus fiable.
C'est vrai. Mais l'expérience montre que c'est la commutation grossière qui est la plus judicieuse.
Les entrées en sont un bon exemple. Après tout, il existe un très grand nombre d'entrées qui peuvent être inventées. Cependant, tous gravitent autour de deux variantes : l'entrée au niveau de la barre coulissante et l'entrée au niveau de la marge du canal. C'est ça ! Peu importe ce que vous pouvez imaginer, la différence entre ces deux variantes sera en unités de pourcentage. Quel est donc le sens de prendre des centaines de variantes d'entrées si elles ne diffèrent pas beaucoup de ces deux qui diffèrent fortement l'une de l'autre ?
Et il en est ainsi des filtres et de l'accompagnement...
Il ne sert à rien de "changer le code en douceur". Le "Step change" s'avère plus fiable.
Il n'existe que deux variantes d'entrées si l'on considère que la barre coulissante et le canal sont immuables, mais dans la pratique, il existe un grand nombre de leurs variations.
Seule cette "grande multitude" diffère d'une EMA ou d'un canal de prix ordinaire de quelques pour cent.
Quelle que soit la moyenne mobile que vous inventez, vous trouverez toujours une EMA qui en sera très proche. La situation est la même avec les canaux - quel que soit le canal que vous inventez, vous trouverez toujours un PriceChannel qui en sera très proche. Dans ce cas, pourquoi avons-nous besoin de cette "grande multitude" ?
Seule cette "grande multitude" diffère d'une EMA ou d'un canal de prix ordinaire de quelques pour cent.
Quelle que soit la moyenne mobile que vous inventez, vous trouverez toujours une EMA qui en sera très proche. La situation est la même avec les canaux - quel que soit le canal que vous inventez, vous trouverez toujours un PriceChannel qui en sera très proche. Et dans ce cas, pourquoi avons-nous besoin de cette "grande multitude" ?
C'est-à-dire que le système fait la moyenne (au sens physique du terme).
Et la moyenne serait de +0% de profit, Georges. Comme moi :))) Je ne veux pas vous assommer - je suis votre signal - mais, hélas, c'est de cela qu'il s'agit.
C'est-à-dire que le système fait la moyenne (au sens physique du terme).
Et la moyenne sera de +0% de profit, Georges. Comme moi :))) Je ne veux pas vous assommer - je suis votre signal - mais, hélas, c'est de cela qu'il s'agit.
Voyons voir. Le système ne peut pas être "moyennant" car les meilleurs CTs travaillent sur le signal. Les pertes sont dues au fait que les systèmes " meurent " et qu'il faut les nettoyer et les remplacer par de nouveaux systèmes. Et, malheureusement, la question de l'évaluation et de la sélection pour la "durabilité" n'est toujours pas résolue.