Erreurs, bugs, questions - page 2511
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
Justifier
Dans certains cas, il est judicieux d'optimiser les indicateurs exactement de la même manière que les EA. Le développeur de l'indicateur connaît la signification appliquée de l'optimisation. Vous avez fait le mode des calculs mathématiques aléatoires, et l'indicateur est en fait un calcul, mais avec une représentation graphique du résultat. Bien entendu, les indicateurs ne peuvent être optimisés et testés que par une valeur personnalisée de OnTester.
J'ai écrit une justification dans le service d'assistance, mais comme l'accès y est complètement fermé maintenant, je ne peux pas donner de détails. Il serait logique de laisser les tâches SD existantes disponibles en mode lecture seule - vous pourriez alors y établir un lien.
Dans certains cas, il est judicieux d'optimiser les indicateurs exactement de la même manière que les EA.
Ensuite, vous pouvez créer un EA avec un gestionnaire d'indicateurs.
La recette donnée n'aide pas du tout. Un onglet est ouvert. J'ai d'abord fait le point en cliquant trois fois sur chacune d'elles.
Puis j'ai écrit un MP, et immédiatement apparu soi-disant six non lus. C'est imbattable.
Ensuite, vous pouvez créer un EA avec une poignée d'indicateurs.
Pourquoi tous ces emballages ? Pourquoi ne pas les mettre en œuvre dans la plate-forme elle-même ? Le testeur a déjà la possibilité de tester à la fois les EA et les indicateurs. Il est absolument illogique que le premier type ait la possibilité de renvoyer une valeur au testeur, alors que le second ne le fait pas.
Pourquoi tous ces emballages ? Pourquoi ne pas les mettre en œuvre dans la plate-forme elle-même ? Le testeur a déjà la capacité de tester à la fois les conseillers experts et les indicateurs. Il est absolument illogique que le premier type ait la possibilité de renvoyer une valeur au testeur, alors que le second ne le fait pas.
Je voulais dire que dans le Testeur, les indicateurs ne sont exécutés que dans le Visualiseur. Et ils n'y exécutent jamais OnDeinit et le destructeur global (même après la fermeture du Visualiseur). Par conséquent, il est un peu difficile de découvrir dans un indicateur que la course s'est arrêtée.
OnTester a été conçu à l'origine comme un critère d'optimisation personnalisé (les indicateurs ne sont pas optimisés et ne s'exécutent même pas en dehors du Visualiseur), et non comme un sémaphore de la fin d'exécution. Le sémaphore dans les conseillers experts a toujours été OnDeinit. Il n'est pas nécessaire de renvoyer quelque chose à l'indicateur dans le Testeur.
Le fait est que dans le testeur, les indicateurs ne sont exécutés que dans la visionneuse. Et OnDeinit et le destructeur global n'y sont jamais exécutés(même après la fermeture du Visualiseur). Il est donc un peu difficile de découvrir dans l'indicateur que la course s'est arrêtée.
OnTester a été conçu à l'origine comme un critère d'optimisation personnalisé (les indicateurs ne sont pas optimisés et ne s'exécutent même pas en dehors du Visualiseur), et non comme un sémaphore de la fin d'exécution. Le sémaphore dans les conseillers experts a toujours été OnDeinit. Et il n'est pas nécessaire de renvoyer quelque chose à l'indicateur dans le Testeur.
Ce caractère gras est le problème même, à cause duquel j'ai écrit le SD. De nombreux indicateurs devraient stocker des statistiques ou des états lors du chargement, mais le testeur ne permet pas de travailler à ce moment-là à cause de l'échec de OnDeinit, sans parler du débogage du code OnDeinit sur l'historique (ce qui est impossible maintenant).
Ce n'est pas si clair que ça. Je pense qu'un programme supporté par un testeur devrait être capable de gérer un événement OnTester de manière purement sémantique, par définition. Le mode visuel ou non visuel est une autre question. Pourquoi ne pouvons-nous pas tester l'indicateur dans un mode non visuel n'est pas non plus clair, car cela aiderait à identifier les problèmes spécifiques dans les calculs de l'indicateur, et en fait, ce mode est toujours là, si nous lançons la visualisation et ensuite utilisons le bouton de date "scroll to" dans la fenêtre.
Si l'indicateur renvoie une valeur au testeur, il peut être optimisé. Je pense que c'est utile, j'ai rencontré ce besoin. Maintenant, le problème est résolu en "dansant avec un tambourin".
Si l'indicateur renvoie une valeur au testeur, il peut être optimisé. Je le trouve utile, j'en ai rencontré le besoin. Maintenant, le problème est résolu en "dansant avec un tambourin".
Que doit renvoyer l'indicateur ? Il n'a qu'un seul paramètre renvoyé à chaque tick.
return(rates_total);Ce que vous envoyez du retour, vous l'obtiendrez au prochain tick dans prev_calculated , nous avons discuté de la façon d'implémenter le "multithreading" dans l'indicateurhttps://www.mql5.com/ru/forum/278924/page4#comment_8679302.
je peux optimiser l'indicateur de la même manière - s'il y a une nouvelle barre, vous avez fait l'optimisation, l'indicateur "voit" les barres, non ? - Pourquoi a-t-il besoin d'un testeur ?
Le mode visuel ou non visuel est une autre question. La raison pour laquelle nous ne pouvons pas tester l'indicateur en mode non visuel n'est pas claire non plus, car cela peut nous aider à identifier des problèmes spécifiques dans les calculs de l'indicateur.
Vous pouvez remettre à zéro les tampons des indicateurs à chaque tick (barre) - c'est le mode non visuel - puis les remplir - c'est le mode visuel.
S'il y a un problème, il n'est pas évident - l'indicateur est "un mappage de tampon (tableau) d'indicateur", la seule chose qui est pratique dans le testeur n'est pas la génération de ticks et de nouvelles barres, mais ce que vous mettez dans le tampon sera - en fait, vous pouvez délecter les tampons pour vérifier les calculs spécifiques de l'indicateur