Bei einem Indikator trat ein Fehler bei der Division durch Null auf - Seite 8
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
Angenommen, wir haben
Wir wissen, dassstart_time2018.04.28 23:00sein sollte.
Es stellt sich also heraus, dass die Zeit hier falsch ist?
Alexey, sieh dir mein Beispiel an. Ich habe dort Zeile für Zeile gezeigt, wie die stündliche Zeit, die Sie überschreiten, in die nächstgelegene Zeit des aktuellen Balkens umgerechnet wird.
Es konnte keine Deklaration des Variablentyps limit gefunden werden. Meine Sehkraft ist schwach.
Posten 50, Prozedur OnCalculate
Beitrag 50, OnCalculate-Prozedur
Danke, aber welcher ist 50? Können Sie mir mit einem Link weiterhelfen?
Danke, aber welche ist die 50? Können Sie mir mit einem Link weiterhelfen?
https://www.mql5.com/ru/forum/262864/page5
Der Link führt nur zu der Seite. In der Überschrift des Beitrags steht #50. Deine #74 ))
Sie haben zuerstlimit=start_index-stop_index+1 geschrieben, d.h.limit==1, und dann wo die Division durch 2 -limit=(int)(stop_time-start_time)/PeriodSeconds(_Period). Eine wird nicht hinzugefügt. Null wird durch die Periode geteilt.
Richtig,limit=start_index-stop_index+1ist für i>0, d.h. für die Berechnung der Historie, und limit=(int)(stop_time-start_time)/PeriodSeconds(_Period) ist für die Berechnung auf dem aktuellen Bar.
Und das ist eigentlich der Grund, warum unsere Zeit so krumm ist - wenn wir einen Zeitrahmen von einer Stunde haben, müssen die Daten rund sein, sowohl am Anfang als auch am Ende - das ist das eigentliche Problem, dass die Taktzeit am Startdatum irgendwie falsch ist!!!
Vielleicht gibt es hier ein Problem.
Da start_time zu diesem Zeitpunkt korrekt ist
datetime start_time=rates[i].time;Alexey, es gibt kein "am Ende". Es ist nur eine Quantisierung. Genau um 18:00 Uhr öffnete sich die Bar, zeigte Minimum und Maximum an und schloss sich sicher in derselben Sekunde.
Ein Beispiel: Der Balken wurde um 18:00 Uhr eröffnet, die Anfangszeit(start_time) ist also 18:00 Uhr und die Endzeit(stop_time) soll 19:00 Uhr für den stündlichen Zeitrahmen sein. Daher wird der Index zwischen ihnen auf dem M1-Zeitrahmen unterschiedlich sein. Und im Code sind der Start- und der Endindex gleich, was nicht stimmt.
Richtig,limit=start_index-stop_index+1ist für i>0, d.h. für die Berechnung der Historie, und limit=(int)(stop_time-start_time)/PeriodSeconds(_Period) ist für die Berechnung auf dem aktuellen Bar.
Und das ist eigentlich der Grund, warum unsere Zeit so krumm ist - wenn wir einen Zeitrahmen von einer Stunde haben, müssen die Daten rund sein, sowohl am Anfang als auch am Ende - das ist das eigentliche Problem, dass die Taktzeit am Startdatum irgendwie falsch ist!!!
Vielleicht gibt es hier ein Problem.
Da start_time zu diesem Zeitpunkt korrekt ist
Und warum sind sie rund, wenn Sie zuerst CopyRates von stündlichen Zeitrahmen (es stellt sich heraus, runde Zahlen), dann übergeben Sie an die ProzedurCreateFigure Zeit aus dem aktuellen Zeitrahmen (Zeit, die sich in Time) und Raten von stündlichen Zeitrahmen, und dann für den Index in das Array der aktuellen Zeitrahmen suchen?start_index=ArrayBsearch(Time,start_time);