Caractéristiques du langage mql5, subtilités et techniques - page 107
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
Cela signifie probablement qu'un seul passage peut durer plus de ~50 jours.
non, Slava a bien compris et l'a dit.
La densité de temps dans le testeur est complètement différente. Ça ne marchera pas.
Je me suis trompé.
J'étais sûr que dans le testeur la fonctionGetTickCount() émule des valeurs basées sur le temps de test.
Très étrange et illogique. Une surprise pour moi. Cela signifie que GetTickCount() est simplement "gelé" dans le testeur.
J'avais tort.
J'étais sûr que la fonction GetTickCount() du testeur émulait des valeurs basées sur l'heure du test.
Très étrange et pas logique. Une surprise pour moi. C'est-à-dire qu'il faut comprendre que GetTickCount() se "fige" simplement dans le testeur.
Pourquoi est-ce illogique ?
Il est tout à fait logique de regrouper les appels OnTick, OnCalculate, OnInit, OnDeinit, etc. en un seul appel. Les calculs peuvent être très différents en termes de gravité.
Non, Slava a bien compris et l'a dit.
Non, il ne l'a pas fait.
Si 50 jours exactement se sont écoulés depuis le début du programme, la différence sera de quelques heures.
Mais si vous utilisezGetMicrosecondCount() au lieu de GetTickCount(), alors le temps de non-débordement sera de 584542 ans au lieu de 50 jours
ZY Pour être plus exact 583081 ans si vous considérez le calendrier grégorien ;))
Pourquoi est-ce illogique ?
Un appel unique à OnTick, OnCalculate, OnInit, OnDeinit, etc. est assez logique. Les calculs peuvent être très différents en termes de gravité.
Eh bien oui, c'est logique pour mesurer le temps d'exécution des calculs d'une fonction ou d'un bloc de code. Les fonctions GetTickCount() etGetMicrosecondCount() sont inutiles dans le testeur pour le reste, par exemple pour mesurer le temps entre certains événements.
Non, ça ne l'est pas.
Si 50 jours exactement se sont écoulés depuis le début du programme, la différence sera de quelques heures.
Ces intervalles ne sont pas mesurés
Pour être honnête, même si un tel cas est pris en compte, COMMENT le prendre en compte - je ne sais pas.
ces écarts ne sont pas mesurés
Et pour être honnête, même si un tel cas est pris en compte, COMMENT le prendre en compte - je ne sais pas.
Non, bien sûr, vous n'avez pas à vous en inquiéter. 50 jours - cela va vraiment au-delà de l'application pratique. Si vous avez vraiment besoin de tester plus de 50 jours, il vaut mieux utiliserGetTickCount(), car c'est plus facile, mais avec un contrôle de débordement (il y aura une variable supplémentaire).
En fait, le sujet de l'heure locale dans le testeur est très toxique pour la concurrence loyale. Tout n'est que mensonges blancs.
Si j'étais MQ, je fermerais toutes ces failles pour déterminer l'heure locale, car ce n'est pas nécessaire dans le testeur, et ce n'est nécessaire que pour faire des bêtises aux nouveaux traders crédules.
Eh bien, ou au moins retirer ce sujet de ce fil et des autres, si possible.
En fait, le sujet soulevé de l'heure locale dans le testeur est très toxique pour la concurrence loyale. Tout est couvert de mensonges blancs.
Si j'étais MQ, je supprimerais toutes ces failles dans la définition de l'heure locale, car cela n'est pas nécessaire dans le testeur, et seulement nécessaire pour tromper les nouveaux traders crédules.
Eh bien, ou au moins retirer le sujet de ce fil et des autres, si possible.
Aucune tromperie ne peut être supportée par le sujet. Quant à l'application pratique, je l'utilise en KB. C'est pratique.