Fehler, Irrtümer, Fragen - Seite 2180
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
Ganz klar: Null.
Ist es in Ordnung, wenn man 22 Sekunden braucht, um zu entscheiden, dass es in einem bestimmten Zeitrahmen keine Balken gibt?
Offensichtlich ein algorithmischer Fehler in der internen Implementierung von Bars.
Und ich verstehe nicht, wie Sie null Balken in einem bestimmten Zeitrahmen von dieser Null unterscheiden:
Aus der Dokumentation: Wenn die Daten für eine Zeitreihe mit den angegebenen Parametern beim Aufruf der Funktion Bars() noch nicht im Terminal generiert sind oder die Zeitreihendaten zum Zeitpunkt des Funktionsaufrufs nicht mit dem Handelsserver synchronisiert sind, gibt die Funktion den Wert Null zurück.
Mit anderen Worten: Wie kann ich zwischen einem Null-Ergebnis und einem Null-Fehler unterscheiden?Und ich verstehe nicht, wie Sie zwischen Null-Balken in einem bestimmten Zeitrahmen und dieser Null unterscheiden:
Aus der Dokumentation: Wenn die Daten für eine Zeitreihe mit den angegebenen Parametern beim Aufruf der Funktion Bars() noch nicht im Terminal generiert wurden oder die Zeitreihendaten zum Zeitpunkt des Funktionsaufrufs nicht mit dem Handelsserver synchronisiert sind, gibt die Funktion den Wert Null zurück.
Der Ursprung des Nullpunkts ist in dieser Frage nicht wichtig, wichtig ist, dass dieser Nullpunkt für immer in Form von ein paar Dutzend Sekunden von der Balkenfunktion getragen wird.
Was ich nicht verstehe, ist, wie Sie zwischen Null-Balken in einem bestimmten Zeitrahmen und dieser Null unterscheiden:
Aus der Dokumentation: Wenn Daten für eine Zeitreihe mit angegebenen Parametern beim Aufruf der Funktion Bars() noch nicht im Terminal generiert wurden oder Zeitreihendaten zum Zeitpunkt des Funktionsaufrufs nicht mit dem Handelsserver synchronisiert sind, gibt die Funktion Null zurück.
Mit anderen Worten: Wie kann ich zwischen einem Null-Ergebnis und einem Null-Fehler unterscheiden?Überlegen Sie es sich. Wenn Sie die Aufgabe hätten, ein Analogon der Funktion Balken zu erstellen, und Sie bekämen ein Array datetime, dessen Werte mit zunehmender Anzahl abnehmen, d. h. das Array ist sortiert.
Glauben Sie, dass es schwierig wäre, einen Algorithmus zu implementieren, der die Anzahl der Elemente einer solchen sortierten Anordnung in einem bestimmten Zeitintervall ermittelt? Und wenn es keinen einzigen Balken in dem angegebenen Intervall gibt oder das Array noch nicht initialisiert wurde, sollten wir Null zurückgeben.
Nein - der Algorithmus ist einfach genug. Was kann es 22 Sekunden lang laufen?
In dieser Frage ist der Ursprung des Nullpunkts nicht wichtig, wichtig ist, dass dieser Nullpunkt seit Ewigkeiten in Form von ein paar Dutzend Sekunden von der Balkenfunktion getragen wird.
Gerade der Ursprung ist wichtig, denn wenn ::Bars() im Falle eines Verlaufsfehlers -1 statt 0 (wie jetzt) zurückgeben würde, hätten wir keine Verzögerung. Aber jetzt wird 0 als Fehler interpretiert und die Verzögerung ist auf interne Wiederholungen zurückzuführen https://www.mql5.com/ru/forum/1111/page2200#comment_6955559
Angenommen, wir führen eine zusätzliche Prüfung ein und die Verzögerung verschwindet. Was ist dann passiert? Sie haben null. Ist dies ein Ergebnis oder ein Fehler?
Dies ist höchstwahrscheinlich auf die historische Belastung zurückzuführen
Das Seltsame ist, dass der erste Druck ohne Verzögerung verarbeitet wird, d.h. die Historie von H4 ist bereits geladen.
Und wenn Sie CopyTime H4 auf W1 ändern, gibt es überhaupt keine Verzögerung. Das bedeutet, dass auch die Geschichte für W1 bereits geladen ist.
Es ist nur so, dass Bars durch das Zeitintervall zwischen CurrentTime() und der Null-Bar-Open-Zeit gehemmt wird.
Es kommt auf den Ursprung an, denn wenn ::Bars() im Falle eines Verlaufsfehlers -1 statt 0 zurückgeben würde (wie es jetzt der Fall ist), gäbe es überhaupt keine Verzögerung. Aber jetzt wird 0 als Fehler interpretiert und es kommt zu Verzögerungen durch interne Wiederholungen https://www.mql5.com/ru/forum/1111/page2200#comment_6955559.
Angenommen, es wird eine zusätzliche Kontrolle eingeführt und die Verzögerung wird aufgehoben. Was ist dann passiert? Sie haben null. Ist dies ein Ergebnis oder ein Fehler?
Bei all meinen Algorithmen spielt es keine Rolle, ob das Ergebnis der Null ein Balken ist, der nicht in das gegebene Intervall fällt, oder das Fehlen eines Feldes als solches.
Sie führen vom Problem weg.
Sie lenken vom Problem ab.
Ich spreche den Kern des Problems an, Sie sind auf Ihren speziellen Fall fixiert. Nach Ihrem vorherigen Beitrag zu urteilen, verstehen Sie immer noch nicht, wann eine Verzögerung auftritt (das ist neben der Ursache), obwohl auf der vorherigen Seite alles im Detail erklärt wird.
Vielleicht hilft Ihnen dieses Skript beim Verständnis
Ich erkläre den Kern des Problems, während Sie auf Ihren speziellen Fall fixiert sind. Ihrer vorherigen Nachricht nach zu urteilen, verstehen Sie immer noch nicht, wann eine Verzögerung eintritt (das ist neben dem Grund), obwohl die vorherige Seite dies ausführlich erklärt.
Ich habe bereits weiter oben meine Meinung dazu geäußert, wann die Verzögerung eintritt.
Noch einmal:
Bars hängt sich auf, wenn start_time im Bereich von der Eröffnungszeit des Nullbalkens der angeforderten TF bis TimeCurrent() liegt. (Nur eine Hypothese, aber in der Praxis überprüft)
Ja, der Fehler tritt in einem speziellen Fall auf. Aber private Fälle sollten nicht in standardmäßig eingebauten Programmiersprachenfunktionen enthalten sein.
Und Ihr "Punkt" ist nicht der Punkt, denn Sie zitieren einfach den Verweis auf den Barrenbefehl, der mir sehr wohl bekannt ist. Die Funktion Bars enthält keinen Fehlercode, da sie nicht benötigt wird.
Umso mehr haben wir es in diesem Fall mit voll ausgebildeten Arrays von Zeitreihen zu tun.
Dies ist in dem leicht geänderten Code meines Skripts deutlich zu erkennen:
Ergebnis:
Vielleicht hilft dieses Skript beim Verständnis
Ihr Skript demonstriert dieses Problem - es hängt.
weil der Zeitbereich start_time - stop_time innerhalb des wöchentlichen Balkens liegt.
Wenn Sie über die Wochenleiste hinausgehen, gibt es kein Einfrieren:
Vielen Dank für das anschauliche Beispiel
In MT4 verursachten die Funktionen CopyHigh und CopyLow (andere habe ich mir nicht angeschaut) einen kritischen Fehler, wenn keine Historie im Tester vorhanden war. EA wurde auf H1 getestet und die Anfrage kam von M1
1 15:14:35.410 2017.01.04 19:54:24 Access violation read to 0x0A971FE8 in 'C:\Users\Halyna\AppData\Roaming\MetaQuotes\Terminal\287469DEA9630EA94D0715D755974F1B\MQL4\Experts\____________.ex4'
3 15:14:35.465 2017.01.04 19:54:24 Testdurchlauf gestoppt aufgrund eines kritischen Fehlers im EA