Le système de trading mécanique parfait. - page 4
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
Jusqu'à présent, tout me semble beaucoup plus simple. Vous devriez commencer par un système simple et naïf, avec un minimum de paramètres de réglage, et y ajouter un bloc de changements de paramètres adaptatifs en temps réel...
Voilà, il ne reste plus grand chose :) Nous devons décider quelles données utiliser pour calculer les paramètres adaptatifs. Je ne sais même pas quoi suggérer :(
Quelqu'un a-t-il une idée à ce sujet ?
Je peux commencer par proposer le modèle de CT suivant :
Nous prenons un Expert Advisor simple et lui écrivons un bloc "testeur" (dont la tâche sera - une fois par jour par exemple à 01:00 GMT d'ajuster TS sous l'historique mensuel).
xeon, on peut faire fonctionner le testeur tout le temps. Bien sûr, il faudrait l'écrire en C hautement optimisé, pas en mql4. Hélas, il y a un écueil très sérieux dans tout cela. Il s'agit de la période d'estimation et d'optimisation du système. C'est-à-dire pendant combien de temps pour évaluer ses performances ? Supposons que nous ayons deux stratégies qui se disputent le droit de faire du commerce réel. L'actuelle réussie et la pire. En l'espace d'une heure, par exemple, la stratégie actuelle a perdu de l'argent, alors que la stratégie de secours a au contraire réussi. La question est de changer de stratégie ou de ne pas changer ? Après tout, cela peut être le début d'une nouvelle tendance (à ne pas confondre avec tendance/flit !), ou accidentel. Il s'avère qu'un tel testeur aurait lui-même au moins un (et important ! !!) paramètre configurable - la période d'évaluation et d'optimisation. Ne croyez pas que je dise qu'une telle approche est impossible. Je dis juste qu'il y a des difficultés et des endroits obscurs dans tout ça.
Essayons une approche simple après tout.
La tâche : est-il possible d'écrire une fonction qui exécute l'historique mensuel une fois par jour et fixe le nombre optimal pour le paramètre stop loss ?
ET LE PLUS IMPORTANT : Puis-je utiliser cette fonction pour contrôler le testeur ? Le testeur fonctionnera-t-il ? Il s'avère que chaque jour en mode test il faut changer le paramètre d'arrêt pour un nouveau jour, est-ce possible ? Si cette tâche est résolue, le reste n'est que du glaçage comme déjà dit.
xeon, on peut faire fonctionner le testeur tout le temps. Bien sûr, il faudrait l'écrire en C hautement optimisé, pas en mql4. Hélas, il y a un piège très sérieux dans tout cela. Il s'agit de la période d'estimation et d'optimisation du système. C'est-à-dire pendant combien de temps pour évaluer ses performances ? Supposons que nous ayons deux stratégies qui se disputent le droit de faire du commerce réel. L'actuelle réussie et la pire. En l'espace d'une heure, par exemple, la stratégie actuelle a perdu de l'argent, alors que la stratégie de secours a au contraire réussi. La question est de changer de stratégie ou de ne pas changer ? Après tout, cela peut être le début d'une nouvelle tendance (à ne pas confondre avec tendance/flit !), ou accidentel. Il s'avère qu'un tel testeur aurait lui-même au moins un (et important ! !!) paramètre configurable - la période d'évaluation et d'optimisation. Ne croyez pas que je dise qu'une telle approche est impossible. Je dis juste qu'il y a des difficultés et des endroits obscurs dans tout ça.
Essayons une approche simple après tout.
La tâche : est-il possible d'écrire une fonction qui exécute l'historique mensuel une fois par jour et fixe le nombre optimal pour le paramètre Stop Loss ?
ET LE PLUS IMPORTANT : Puis-je utiliser cette fonction pour contrôler le testeur ? Le testeur fonctionnera-t-il ? Il s'avère que chaque jour en mode test il faut changer le paramètre d'arrêt pour un nouveau jour, est-ce possible ? Si vous résolvez ce problème, le reste n'est que du glaçage comme déjà dit.
Pour autant que je sache, il est possible d'écrire une telle fonction dans mql, mais cette tâche n'est pas facile pour moi, car je suis un "programmeur amateur" et j'ai besoin de temps pour le faire.
Les indicateurs auto-ajustables sont une impasse. Je vais essayer de justifier mon opinion.
J'ai développé plusieurs indicateurs de ce type, mais ils semblaient être sensibles à la volatilité des cotations provenant de différentes sociétés de courtage. C'est-à-dire que ces indicateurs fonctionnent bien sur les données d'une société de courtage et ne fonctionnent pas du tout sur les données d'une autre société. Le pire, c'est qu'ils travaillent avec les données du CT. Par exemple sur les indicateurs standards sur le même intervalle de cotation il y a une divergence dans une société de courtage et pas dans une autre.
Mes recherches ont montré que la volatilité est le principal facteur à prendre en compte dans un indicateur auto-adaptatif. Cependant, l'indicateur finit par dépendre de la méthode de filtrage des cotations dans les différentes sociétés de courtage et des changements de cette méthode (qui n'est pas notifiée par les sociétés de courtage).
Ici, je suis également confronté au fait que je ne peux pas "durcir" (comme Renat le dit toujours) l'auto-réglage, parce qu'il est constant (linéaire), et non discret.
Je pense que la seule façon d'éviter le problème de la volatilité est d'ignorer les valeurs absolues des indicateurs et des cotations. En d'autres termes, pour prendre une décision dans le SMT, nous devons utiliser la corrélation des valeurs sous une forme ou une autre, et il s'agit essentiellement de la reconnaissance des formes.
le !
Les indicateurs auto-ajustables sont une impasse. Je vais essayer de justifier mon opinion.
J'ai développé plusieurs indicateurs de ce type, mais ils semblaient être sensibles à la volatilité des cotations provenant de différentes sociétés de courtage. C'est-à-dire que ces indicateurs fonctionnent bien sur les données d'une société de courtage et ne fonctionnent pas du tout sur les données d'une autre société. Le pire, c'est qu'ils travaillent avec les données du CT. Par exemple sur les indicateurs standards sur le même intervalle de cotation il y a une divergence dans une société de courtage et pas dans une autre.
Mes recherches ont montré que la volatilité est le principal facteur à prendre en compte dans un indicateur auto-adaptatif. Cependant, l'indicateur finit par dépendre de la manière de filtrer les cotations dans les différentes sociétés de courtage et des changements de cette méthode (qui n'est pas notifiée par les sociétés de courtage).
Ici, je suis également confronté au fait que je ne peux pas "durcir" (comme Renat le dit toujours) l'auto-réglage, car il est constant (linéaire), et non discret.
Je pense que la seule façon d'éviter le problème de la volatilité est d'ignorer les valeurs absolues des indicateurs et des cotations. En d'autres termes, pour prendre une décision dans le SMT, nous devons utiliser la corrélation des valeurs sous une forme ou une autre, et il s'agit essentiellement de la reconnaissance des formes.
Pour tout système, ce n'est pas la valeur du prix qui importe, mais la vitesse de variation du prix (parfois simplement le signe).
On utilise parfois l'accélération du prix (estimation de la force agissant sur le prix, comme indicateur avancé).
TOUS les indicateurs utilisés avec MTS sont en fait conçus pour estimer la vitesse.
Les différents indicateurs sont simplement des OPTIONS différentes pour estimer la vélocité.
1. TOUS les oscillateurs estiment la vitesse, parfois l'accélération (comme le MACD).
2. TOUTES les moyennes mobiles ne sont JAMAIS utilisées seules,
uniquement par rapport aux autres moyennes mobiles (le prix est une moyenne mobile de longueur = 1).
Cette comparaison des moyennes mobiles (en fait la comparaison de leur différence à zéro) est un oscillateur.
3. Ce n'est pas le prix qu'il faut considérer, mais le logarithme du prix.
En logarithmes, tout devient plus simple et plus correct.
Pour de petits changements de prix, il n'y aura pas de différence entre travailler avec le prix et le logarithme,
En cas de variation importante du prix, la différence sera significative.
Je peux te donner un petit indice ? :)
Pour tout système, ce ne sont pas les valeurs des prix qui sont importantes, mais la vitesse de changement des prix (parfois simplement le signe).
On utilise parfois l'accélération du prix (estimation de la force agissant sur le prix, comme indicateur avancé).
TOUS les indicateurs utilisés avec MTS sont en fait conçus pour estimer la vitesse.
Les différents indicateurs sont simplement des OPTIONS différentes pour estimer la vélocité.
1. TOUS les oscillateurs estiment la vitesse, parfois l'accélération (comme le MACD).
2. TOUTES les moyennes mobiles ne sont JAMAIS utilisées seules,
uniquement par rapport aux autres moyennes mobiles (le prix est une moyenne mobile de longueur = 1).
Cette comparaison des moyennes mobiles (en fait la comparaison de leur différence à zéro) est un oscillateur.
3. Ce n'est pas le prix qu'il faut considérer, mais le logarithme du prix.
En logarithmes, tout devient plus simple et plus correct.
Pour de petits changements de prix, il n'y aura pas de différence entre travailler avec le prix et le logarithme,
lors de changements de prix importants, la différence sera significative.
Ou peut-être souhaitez-vous participer à l'écriture du code ? :-), avec votre expérience de la programmation, cela irait beaucoup plus vite !