Fehler, Irrtümer, Fragen - Seite 2180

 
Nikolai Semko:

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?
 
A100:

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.

 
A100:

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?

 
Nikolai Semko:

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?

Ошибки, баги, вопросы
Ошибки, баги, вопросы
  • 2018.03.31
  • www.mql5.com
Общее обсуждение: Ошибки, баги, вопросы
 
Vitaly Muzichenko:

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.

 
A100:

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.

 
Nikolai Semko:

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

void OnStart()
{
        Print( "begin" );
        ::Bars( _Symbol, PERIOD_W1, D'2018.03.20', D'2018.03.23' );
        Print( "end" );
}
 
A100:
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:

void OnStart()
  {
   datetime Arr[];
   if(CopyTime(_Symbol,PERIOD_W1,0,1,Arr)<0) Print("Ошибка");
   Print("Время открытия нулевого бара W1 = "+TimeToString(Arr[0]));
   ArraySetAsSeries(Arr,true);
   if(CopyTime(_Symbol,PERIOD_H4,0,100,Arr)<0) Print("Ошибка");
   Print("1 "+"CurrentTime = "+TimeToString(TimeCurrent()));
   int Res=Bars(_Symbol,PERIOD_W1,Arr[99],TimeCurrent());  // выполняется быстро   
   Print("2 Время открытия 99 бара H4 = "+TimeToString(Arr[99])+"  Номер бара W1= " +IntegerToString(Res)); 
   Res=Bars(_Symbol,PERIOD_W1,Arr[0],TimeCurrent());       // выполнение происходит более 10 секунд!!!   
   Print("3 Время нулевого бара H4 = "+TimeToString(Arr[0])+"  Номер бара W1= " +IntegerToString(Res));
  }

Ergebnis:

2018.03.30 23:39:31.079 BagBars (EURUSD,H4)     Время открытия нулевого бара W1 = 2018.03.25 00:00
2018.03.30 23:39:31.079 BagBars (EURUSD,H4)     1 CurrentTime = 2018.03.30 23:54
2018.03.30 23:39:31.079 BagBars (EURUSD,H4)     2 Время открытия 99 бара H4 = 2018.03.08 20:00  Номер бара W1= 3
2018.03.30 23:39:47.176 BagBars (EURUSD,H4)     3 Время нулевого бара H4 = 2018.03.30 20:00  Номер бара W1= 0
 
A100:

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:

Bars( _Symbol, PERIOD_W1, D'2018.03.12', D'2018.03.23' );

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