Merkmale der Sprache mql5, Feinheiten und Techniken - Seite 107
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Damit ist wahrscheinlich gemeint, dass ein einziger Durchgang länger als ~50 Tage dauern kann.
Nein, Slawa hat es richtig verstanden und gesagt.
Die Zeitdichte im Prüfgerät ist völlig anders. Es wird nicht funktionieren.
Ich habe mich geirrt.
Ich war mir sicher, dass die FunktionGetTickCount() im Tester Werte auf der Grundlage der Testzeit emuliert.
Sehr seltsam und unlogisch. Eine Überraschung für mich. Das bedeutet, dass GetTickCount() im Testgerät einfach "einfriert".
Ich habe mich geirrt.
Ich war mir sicher, dass die Funktion GetTickCount() im Tester Werte emuliert, die auf dem Zeitpunkt des Tests basieren.
Sehr seltsam und unlogisch. Eine Überraschung für mich. D.h. es sollte klar sein, dass GetTickCount() im Testgerät einfach "einfriert".
Warum ist das unlogisch?
Innerhalb eines Aufrufs OnTick, OnCalculate, OnInit, OnDeinit usw. ist recht logisch. Die Berechnungen können sehr unterschiedlich streng ausfallen.
Nein, Slawa hat es richtig verstanden und gesagt.
Nein, hat er nicht.
Wenn seit dem Start des Programms genau 50 Tage vergangen sind, zeigt die Differenz einige Stunden an.
Aber wenn SieGetMicrosecondCount() anstelle von GetTickCount() verwenden, dann wird die Zeit des Nichtüberlaufens 584542 Jahre anstatt 50 Tage betragen
ZY Um genauer zu sein 583081 Jahre, wenn Sie den Gregorianischen Kalender berücksichtigen ))
Warum ist das unlogisch?
Innerhalb eines einzigen Aufrufs von OnTick, OnCalculate, OnInit, OnDeinit usw. ist das durchaus logisch. Die Berechnungen können sehr unterschiedlich streng ausfallen.
Nun ja, es ist nur logisch, die Ausführungszeit von Berechnungen einer Funktion oder eines Codeblocks zu messen. Die Funktionen GetTickCount() undGetMicrosecondCount() sind im Tester ansonsten nutzlos, z. B. für die Messung der Zeit zwischen bestimmten Ereignissen.
Nein, ist es nicht.
Wenn seit dem Start des Programms genau 50 Tage vergangen sind, beträgt die Differenz einige Stunden.
Solche Intervalle werden nicht gemessen
Um ehrlich zu sein, selbst wenn ein solcher Fall in Betracht gezogen wird, weiß ich nicht, WIE er zu berücksichtigen ist.
solche Lücken werden nicht gemessen
Und um ehrlich zu sein, selbst wenn ein solcher Fall in Betracht gezogen wird, weiß ich nicht, WIE er zu berücksichtigen ist.
Nein, natürlich müssen Sie sich darüber keine Gedanken machen. 50 Tage - das sprengt wirklich den Rahmen der praktischen Anwendung. Wenn Sie wirklich mehr als 50 Tage testen müssen, verwenden Sie besser immer nochGetTickCount(), weil es einfacher ist, nur mit Überlaufkontrolle (es wird eine zusätzliche Variable geben).
In der Tat ist das Thema Ortszeit im Testgerät sehr giftig für den fairen Wettbewerb. Das sind alles Notlügen.
Wenn ich MQ wäre, würde ich all diese Schlupflöcher schließen, um die Ortszeit zu bestimmen, denn sie wird im Tester nicht benötigt, sondern nur für die leichtgläubigen, neu geprägten Händler.
Nun, oder zumindest entfernen Sie dieses Thema aus diesem Thread und anderen, falls vorhanden.
In der Tat ist das Thema Ortszeit, das im Tester angesprochen wird, sehr schädlich für den fairen Wettbewerb. Alles ist mit Notlügen überzogen.
Wenn ich MQ wäre, würde ich all diese Schlupflöcher für die Definition der Ortszeit schließen, da dies im Tester nicht notwendig ist und nur dazu dient, die leichtgläubigen neuen Händler zu täuschen.
Oder zumindest das Thema aus diesem und anderen Threads herausnehmen, falls vorhanden.
Keine Täuschung kann vom Thema getragen werden. Was die praktische Anwendung anbelangt, so verwende ich sie in KB. Das ist praktisch.