Erreurs, bugs, questions - page 1961
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
Ahem... L'inverse de "TOSTRING" est-il résolu ?
Malheureusement, là encore, ce problème n'est résolu qu'en mode Optimisation, ou plus précisément, FRAME_MODE.
Dans une exécution normale de l'EA (pas un testeur), une liste des paramètres d'entrée avec les valeurs est facilement obtenue par l'analyse syntaxique de ChartSaveTemplate.
Malheureusement, une fois encore, le problème n'est résolu qu'en mode Optimisation, plus précisément - FRAME_MODE.
L'option "optimisation + test" convient parfaitement à l'affichage pratique des paramètres d'entrée des passages uniques après optimisation.
Mais comment obtenir une liste de paramètres lors d'une seule passe, autrement qu'à partir du fichier préparé lors de l'optimisation ? Et comment comparer les paramètres de ce fichier avec les valeurs utilisées dans le test ?
N'est-ce pas une erreur que const-method puisse changer le champ de sa structure après tout ?
Huh, ce n'est pas this.i, mais une autre instance de Struct.i qui est modifiée dans le code ci-dessus. Il n'y a pas d'erreur. Pour bloquer la modification d'un paramètre structurel, il faut également le déclarer comme const.
L'option "optimiser + tester" permet d'afficher facilement les paramètres d'entrée d'une seule passe après l'optimisation.
Mais comment obtenir une liste de paramètres lors d'une seule passe, autrement qu'à partir du fichier préparé lors de l'optimisation ? Et comment comparer les paramètres de ce fichier avec les valeurs utilisées dans le test ?
Seulement si on fait l'optimisation imaginaire en deux passes, au lieu d'une seule.
Huh, dans le code ci-dessus, ce n'est pas this.i qui est modifié, mais une autre instance de Struct.i. Il n'y a pas d'erreur. Pour bloquer la modification du paramètre Struct, il faut également le déclarer comme const.
Oui, le mécanisme est clair.
Seulement si vous effectuez une optimisation imaginaire en deux passes, au lieu d'une seule.
Et comment les paramètres de ce fichier correspondent-ils aux valeurs utilisées dans le test ?
Andrey Khatimlianskii:
Et comment les paramètres de ce fichier correspondent-ils aux valeurs utilisées dans le test ?
Via ParameterSetRange.
Via ParameterSetRange.
En quoi cela peut-il aider ?
L'optimisation est passée par là, nous avons écrit tous les paramètres à rechercher avec des fourchettes de valeurs.
Puis nous exécutons un seul test, nous lisons la liste des paramètres et nous l'affichons : paramètre = valeur. Dans ce cas, nous ne connaissons pas la valeur, car nous ne pouvons pas accéder à la variable intuitive par son nom.
En quoi cela peut-il aider ?
L'optimisation est passée par là, nous avons noté tous les paramètres à rechercher avec des plages de valeurs.
Puis nous exécutons un seul test, nous lisons la liste des paramètres et nous l'affichons : paramètre = valeur. Dans ce cas, nous ne connaissons pas la valeur, car nous ne pouvons pas nous référer à la variable intuitive par son nom.
Vous faites le paramètre d'entrée bool Optim. Dans OnInit, vous renvoyez INIT_FAILED si Optim == true. En même temps dans OnTesterPass à travers FrameInputs et ParameterGetRange (ou dans le destructeur de l'objet global de la classe) vous écrivez le SET réel d'Optimisation.
Ensuite, vous mettez Optim = false. Et prenez un autre paramètre sinput int Range, définissez-le par ParameterSetRange pour passer de zéro à un. Lire le fichier SET dans OnTesterInit et définir les valeurs de tous les paramètres du fichier dans ParameterSetRange. Lorsque Range == 0, vous renvoyez INIT_FAILED dans OnInit.
C'est tout ! Au lieu de l'optimisation simple, vous avez l'optimisation imaginaire, qui est également plus rapide que l'optimisation simple..... Plus les paramètres d'entrée en lecture/écriture.