Testeur de stratégie MetaTrader 5 : bugs, anomalies, suggestions d'amélioration - page 59
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
Les paramètres de la ligne de résultat de l'optimisation sont corrects, ils correspondent aux paramètres du journal du testeur, mais le conseiller expert est exécuté pour un test avec des paramètres complètement différents.
J'ai désactivé les paramètres d'entrée dans le conseiller expert lui-même. Ils sont assortis.
C'est juste que les données du symbole original correspondent parfaitement à celles du symbole personnalisé. Mais le modèle personnalisé passe sans erreur, alors que le modèle original ne passe pas.
Apparemment, je n'ai pas compris. Le script n'écrit que le csv. Comment fait-on un test sur eux ?
Apparemment, je n'ai pas compris. Le script n'écrit que des csvs. Comment se déroule le test sur eux ?
Le script crée un symbole personnalisé et le symbole original (importé côté serveur) à partir de ces csv.
C'est-à-dire que les deux symboles ont un historique de cotation identique, à la fois en barres et en ticks.
Le script crée un symbole personnalisé et le symbole original(importé côté serveur) à partir de ces csv.
C'est-à-dire que les deux symboles ont un historique de cotation identique, à la fois en barres et en ticks.
Cela aurait dû être mentionné.
Je ne connais pas les mécanismes du serveur MT5 pour travailler avec l'historique.
Pendant la génétique, le numéro de passe de FrameNext ne correspond pas au numéro de passe du fichier opt.
Par exemple, FrameNext renvoie 10041014291 et opt renvoie 2465.
Quelle est la raison de ces différences ? Comment faire correspondre l'un à l'autre ?
Dans le tableau GUI, au lieu du numéro de passe, il y a deux numéros. Mais dès que je rouvre le fichier opt après l'optimisation, les numéros de passage deviennent des valeurs vides.
Veuillez clarifier pour GA.
J'ai appris à reproduire le décalage entre l'AG et l'AG unique. L'AG sauvegardé passe par les stats des cadres. Mais je n'arrive pas à identifier parmi les 10 000 laissez-passer celui qui m'intéresse. Parce que le Pass in FrameNext et le Pass in opt sont des valeurs différentes.
Pendant la génétique, le numéro de passe de FrameNext ne correspond pas au numéro de passe du fichier opt.
Par exemple, FrameNext renvoie 10041014291 et opt renvoie 2465.
Quelle est la raison de ces différences ? Comment faire correspondre l'un à l'autre ?
Dans le tableau GUI, au lieu du numéro de passe, il y a deux numéros. Mais dès que je rouvre le fichier opt après l'optimisation, les numéros de passage deviennent des valeurs vides.
Veuillez clarifier pour GA.
J'ai appris à reproduire le décalage entre l'AG et l'AG unique. L'AG sauvegardé passe par les stats des cadres. Mais je n'arrive pas à identifier, parmi 10 000 laissez-passer, celui qui m'intéresse. Parce que le Pass in FrameNext et le Pass in opt sont des valeurs différentes.
2 numéros - numéro de génération, numéro individuel.
Si vide, le résultat est chargé à partir du fichier opt (c'est-à-dire le résultat de l'optimisation génétique précédente).
Il existe deux types de génétique
1. l'espace des paramètres est limité à un nombre de 64 bits. Dans ce cas, le calcul de la composition des paramètres par le numéro de génotype est réduit à un ensemble d'opérations arithmétiques simples.
2. l'espace des paramètres est limité par un nombre maximal de 64 bits en bas, et de 1024 bits en haut. Une transformation plus complexe du génotype en un ensemble de paramètres. Il semble qu'il s'agisse d'une erreur de numérotation, puisque les trames ne contiennent que les 64 bits les plus bas du numéro de passe.
Dès qu'un nouveau paramètre est ajouté à l'optimisation ou que le start-stop d'un paramètre existant est modifié, toute la numérotation change. Par conséquent, il ne faut pas se baser sur le numéro du laissez-passer, mais sur la composition des paramètres.
2 numéros - numéro de génération, numéro individuel.
Si vide, le résultat est chargé à partir du fichier opt (c'est-à-dire le résultat de l'optimisation génétique précédente).
Il existe deux types de génétique
1. l'espace des paramètres est limité à un nombre de 64 bits. Dans ce cas, le calcul de la composition des paramètres par le numéro de génotype est réduit à un ensemble d'opérations arithmétiques simples.
2. l'espace des paramètres est limité par un nombre maximal de 64 bits en bas, et de 1024 bits en haut. Une transformation plus complexe du génotype en un ensemble de paramètres. Il semble qu'il s'agisse d'une erreur de numéro, car les trames ne contiennent qu'un numéro de passage de 64 bits maximum.
Dès qu'un nouveau paramètre est ajouté à l'optimisation ou que le start-stop d'un paramètre existant est modifié, toute la numérotation change. Ne vous fiez donc pas au numéro de la passe, mais à la composition des paramètres.
Merci. Comment faire correspondre FrameNext_Pass et opt-Pass alors ?
J'ai appris à reproduire le décalage entre GA et simple. Sauvé l'AG passe par les cadres stats. Mais je n'arrive pas à identifier celui qui m'intéresse parmi les 10 000 laissez-passer. Parce que le Pass in FrameNext et le Pass in opt sont des valeurs différentes.
J'ai trouvé la raison de la divergence !
Comparaison de la pile obtenue par le cadre lors de l'optimisation GA. Et la pile d'un seul passage.
Dans le frame-state, l'exécution est basée sur des ticks qui ne sont pas présents dans l'historique : j'ai remarqué immédiatement qu'il y a beaucoup de transactions/ordres, qui sont exécutés en une seconde exactement.
Par exemple, une passe unique dans l'historique a une entrée à 2019.06.04 02:00:00.206, mais une passe de cadre est 2019.06.04 02:00:00.000(l'historique des tics n'a pas de tic à ce moment-là).
L'optimisation GA suit un historique différent de celui de la passe unique ! Et cette histoire n'est pas toujours différente. Par exemple, lorsque je fais des GA sur un intervalle plus petit, tout va bien.
La méfiance de ZZY à l'égard de l'utilisation d'un minuteur tombe. Il n'y a pas de minuterie dans l'EA.
J'ai trouvé la raison de la divergence !
Comparaison des statistiques image par image pendant l'optimisation GA. Et la pile d'un seul passage.
Dans le frame-state, l'exécution est basée sur les ticks, qui ne sont pas dans l'historique : j'ai immédiatement remarqué qu'il y a beaucoup de transactions/ordres, qui sont exécutés en une seconde exactement.
Par exemple, une passe unique dans l'historique a une entrée à 2019.06.04 02:00:00.206, mais une passe de cadre est 2019.06.04 02:00:00.000(l'historique des tics n'a pas de tic à ce moment-là).
L'optimisation GA suit un historique différent de celui de la passe unique ! Et cette histoire n'est pas toujours différente. Par exemple, lorsque je fais des GA sur un intervalle plus petit, tout va bien.
La suspicion de ZZY à l'égard de l'utilisation d'un minuteur tombe. Il n'y a pas de minuterie dans l'EA.
Test/optimisation sur des ticks réels ?
Les agents sont-ils les vôtres ou proviennent-ils du cloud ?
Si vous effectuez des tests sur un symbole personnalisé, les agents en nuage ne sont pas concernés. Les agents sont donc en interne et vous pouvez extraire leurs journaux et voir dans les journaux comment l'historique a été synchronisé.