Toute question de débutant, afin de ne pas encombrer le forum. Professionnels, ne passez pas à côté. Nulle part sans toi - 6. - page 557
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
Je n'ai aucune objection aux principes, mais l'homme veut exécuter le conseiller expert dans le testeur, donc vos options ne lui conviennent pas.
Utilisez ma variante, elle fonctionnera aussi bien dans la réalité que dans le testeur, mais jusqu'à ce qu'ils aient fait une fonction pour tenir compte automatiquement de l'heure d'été, définissez l'heure de transition pour cette année comme suit
De mars 2013 à novembre 2014 fonctionnera et sera testé correctement. Réglez le décalage en fonction de votre courtierJe ne vais pas chercher où il est écrit que le temps est généré dans le testeur, vous le savez vous-même. Mais dans l'aide, il est spécifiquement dit que
Alors qu'il ne dit rien de spécifique sur StringToTime().
La seule chose à prendre en compte est le temps passé sur le testeur (du serveur DC). Et par conséquent, lors des tests, vous devez avoir un historique du même type de compte sur lequel cette chouette va travailler.
Je ne vais pas chercher où il est dit que le temps est généré dans le testeur, vous le savez vous-même. Mais dans l'aide, il est spécifiquement dit que
Alors qu'il ne dit rien de spécifique sur StringToTime().
La seule chose à prendre en compte est le temps passé sur le testeur (du serveur DC). Et donc, lors des tests, vous devez avoir un historique du même type de compte sur lequel cette chouette fonctionnera.
Alexey, je n'ai pas de question sur la fonction StrToTime() La question est différente. Il reviendra au bon moment, mais 21 heures aujourd'hui, c'est 22 heures avant le 9 mars. C'est pourquoi j'ai écrit des fonctions qui prennent correctement en compte le DST du courtier.
Sans cela, si un conseiller expert fonctionne selon un calendrier précis, il est impossible de le tester. Tout est décalé d'une heure. Il n'y a pas de problèmes dans le commerce réel mais il y a des problèmes avec le testeur. Cela fait longtemps que je demande aux développeurs d'activer la fonction qui calcule les décalages horaires. Ils ont implémenté TimeGMT(), mais il est lié à l'heure locale et au fuseau horaire de l'ordinateur. Et vous devez avoir une équipe de freineurs. Et leur DST est différent du nôtre. Les courtiers se déplacent du premier dimanche de novembre au deuxième dimanche de mars et la Russie (si elle le sera...) du dernier dimanche d'octobre au dernier dimanche de mars. Vous devez donc écrire vos propres fonctions pour l'instant.
Je n'ai aucune objection aux principes, mais l'homme veut exécuter le conseiller expert dans le testeur, donc vos options ne lui conviennent pas.
Utilisez ma variante, il fonctionnera à la fois dans le réel et dans le testeur, mais jusqu'à ce qu'ils n'ont pas fait une fonction pour prendre automatiquement en compte l'heure d'été, définir le moment de la transition à cette année comme
De mars 2013 à novembre 2014 fonctionnera et sera testé correctement. Réglez le décalage en fonction de votre courtierOK. Merci. Je vous ferai part du résultat.
Il est nécessaire de vérifier sur les graphiques < h4 l'heure de la dernière barre du vendredi actuel et du vendredi précédent le 8 mars. Si ces périodes coïncident, la valeur hrd est constante et ne dépend pas du changement d'heure hiver-été et alors tout est simple et fonctionnera correctement pendant les tests, indépendamment du changement d'heure hiver-été.
mais si ces deux heures sont différentes (diffèrent d'une heure), alors comme je l'ai écrit précédemment.
Nous devrions vérifier sur le graphique M1 l'heure de la dernière barre du vendredi actuel et du vendredi précédant le 8 mars. Si ces périodes coïncident, alors la valeur hrd est constante et ne dépend pas du passage à l'heure d'hiver ou d'été, et alors tout est simple et fonctionnera correctement pendant les tests, indépendamment du passage à l'heure d'hiver ou d'été.
mais si ces deux heures sont différentes (diffèrent d'une heure), alors comme je l'ai écrit précédemment.
Pourquoi y a-t-il un temps de 15 minutes dans le code, c'est-à-dire que vous voulez dire que 15 minutes avant la fin de la session le rééquilibrage du portefeuille commence ? J'ai certainement remarqué de tels moments sur mt4 à fresch et j'ai vu de bons niveaux sur certaines paires de devises.
Par exemple, je veux fermer des transactions même 1 minute avant la fin de la session, car lorsqu'un ordre est laissé pour le week-end, il arrive que le lundi le prix d'ouverture puisse sauter de 100, ou 200, ou même plus de pips.
Je ne l'ai pas encore testé. Je le ferai plus tard dans la journée.
Eh bien, cela ne devrait pas fonctionner dans le testeur.
Les fonctions sont basées sur l'heure actuelle, et ce que j'ai écrit ci-dessus fonctionnera car TimeCurrent() et TimeDayOfWeek() fonctionnent correctement. Il suffit d'ajouter la fonction permettant de passer à l'heure d'été et d'hiver, c'est-à-dire le paramètre hrd. Le basculement s'effectue généralement en fonction de l'heure d'été américaine (premier dimanche de novembre, deuxième dimanche de mars), mais certains courtiers n'effectuent pas le basculement.
Si mon courtier est en Russie et que je suis en Ukraine, alors il n'y a pas de changement d'heure d'été ou d'hiver, puis il s'avère qu'il n'y a pas de changement d'heure d'été chez mon courtier, mais seulement l'heure locale ?
Il n'est pas nécessaire de comparer l'heure du courtier et votre heure locale. Vous avez beau bouger votre montre, l'heure de fin de la session du courtier sur le graphique ne change pas. La question portait sur le passage aux cotations d'été des courtiers les 8 et 9 mars, et certains courtiers le font, d'autres non.
J'ai écrit - regardez les graphiques pour les derniers temps de barre avant et après le 9 mars, s'ils sont identiques alors utilisez la dernière option simple, s'ils diffèrent d'une heure alors la plus complexe.
Les gars, chapeau bas :) Les formules DayOfWeek() TimeDayOfWeek(datetimedate) et les formules similaires fonctionneront correctement dans le testeur. Le testeur modélise l'heure du tick qu'il traite, c'est pourquoi DayOfWeek() qui prend la dernière heure connue du serveur fonctionne également. Plus correctement bien sûr, utilisez TimeDayOfWeek(dt1)
En général tout est correct, il ne reste plus qu'à prendre en compte le moment de transition du courtier à l'heure d'hiver - heure d'été, s'il y en a une, comme je l'ai écrit plus haut.