Comment puis-je vérifier si une "optimisation" ou une "optimisation avancée" est en cours ? - page 8
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
J'ai fait une vérification similaire indirectement. Le premier trade est toujours un top up (il est le même pour tous les runs). Par conséquent, j'ai mémorisé HistoryDealGetInteger(ticket, DEAL_TIME) pour la première transaction dans OnTester et je l'ai écrit dans le cadre. Grâce à cette valeur, nous pouvons diviser l'ensemble des exécutions deOnTesterPass en deux parties : l'avant et l'arrière. Si possible, transmettez les valeurs des calculs nécessaires de OnTester à OnTesterPass, alors que le calcul lui-même est déjà effectué dans OnTesterPass.
Oui. Nous devrions donc supprimer l'option "forward" de l'ini et vérifier le mode de fonctionnement du testeur - simple test ou optimisation. De sorte que la fonction ne se déclenche que lors d'un simple test et lorsque la fonction "forward" est sélectionnée ?
Forward = Custom, Optimization = Disabled, OnTester #2 (ils conseillent aussi de jeter dans un testerPass, apparemment, pour travailler en paix) et écrire la rentabilité dans le fichier avec la régression.
Je soupçonne simplement que l'OnTester #2 ne se produit que dans ce cas et dans le cas de l'optimisation avec forward. Mais je ne l'utilise jamais et je me contente
régression vers le fichier par le biais de OnTester #2.
Il n'est pas possible de définir de manière programmatique la limite entre ceci et cela.
Il est trop tard pour remarquer ce sujet. J'ai une solution. Je me suis récemment amusé avec un outil visuel pour les tests de type "back+forward". Je me suis rendu compte qu'il est impossible de le déterminer de manière programmatique, mais les nombres de passages en arrière et en avant coïncident.
Par conséquent, l'heure d'arrivée de la première image de la course en avant peut facilement être trouvée dans le pool des numéros de passage enregistrés.
L'heure de la transaction IN/OUT peut également être fixée. Il y a une image dans le profil où le moment de la course en avant est en pointillé - il est déterminé par le fait.
la piscine elle-même).
Il est trop tard pour remarquer ce sujet. J'ai une solution. Je me suis récemment amusé avec un outil visuel pour les tests de type "back+forward". Je me suis rendu compte qu'il est impossible de le déterminer de manière programmatique, mais les nombres de passages en arrière et en avant coïncident.
Par conséquent, l'heure d'arrivée de la première image de la course en avant peut facilement être trouvée dans le pool des numéros de passage enregistrés.
L'heure de la transaction IN/OUT peut également être fixée. Il y a une image dans le profil où le moment de l'avancement est fixé par une ligne pointillée - il est déterminé par le fait.
ils sont combinés . dans l'optimiseur a été sélectionné = 1/2 période, ce qui est visible dans le graphique. dans la grille de données, une des séries combinées est sélectionnée, sa ligne est visible dans le graphique.
ils sont combinés . dans l'optimiseur, on a sélectionné = 1/2 période, ce qui est visible sur le graphique. dans la grille de données, on a sélectionné l'une des séries combinées, dont la ligne est visible sur le graphique.
Il s'agit d'un alignement sur le dépôt initial du dos. Et par le dépôt initial avant vous pouvez ?
Je l'ai. Ici, l'axe des abscisses correspond à un incrément de temps linéaire. Mais je ne vois pas de problème à la superposition. Seul le dépôt initial sera différent. Avances = période totale de retour.
Mais si nous prenons les graphiques d'incrémentation des bénéfices et que nous prenons le zéro comme base, ce sera à partir du même point.
P.s. Seulement pour moi personnellement, l'utilité d'un tel graphique est discutable
Je l'ai. L'axe des abscisses correspond ici à des incréments de temps linéaires. Mais je ne vois pas de problème à le superposer. Seul le dépôt initial sera différent. Avances = période totale de retour.
Mais si nous prenons les graphiques d'incrémentation des bénéfices et que nous prenons le zéro comme base, ce sera à partir du même point.
Je pense que le dépôt de départ de l'arrière peut être sacrifié - tout le monde comprend qu'il s'agit de toute façon d'une convention. L'essentiel est que tous les attaquants aient le même dépôt de départ.
Je veux dire que la vogue du loup en avant n'est pas loin et qu'ils devraient déjà avoir une sorte d'image standard unifiée.
J'apprécie le fait que le calendrier soit le même pour tous - on peut immédiatement ressentir la densité relative des échanges.
Il est trop tard pour remarquer ce sujet. J'ai une solution. Je me suis récemment amusé avec un outil visuel pour les tests de type "back+forward". Je me suis rendu compte qu'il est impossible de le déterminer de manière programmatique, mais les nombres de passages en arrière et en avant coïncident.
Par conséquent, l'heure d'arrivée de la première image de la course en avant peut facilement être trouvée dans le pool des numéros de passage enregistrés.
L'heure de la transaction IN/OUT peut également être fixée. Il y a une image dans le profil où le moment de l'avancement est en pointillés - il est déterminé par le fait