Ein wenig überrascht :) Ich dachte, ich teile das und stelle eine NICHT rhetorische Frage. - Seite 7
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
Das Problem liegt nicht im Tester, sondern unter realen Bedingungen, wo die Daten heruntergeladen werden und Verbindungsfehler auftreten.
Wenn eine Rückstellung und Neuberechnung des Indikators im wirklichen Leben erfolgt, ist daran nichts auszusetzen.
Eine weitere Frage ist aufgetaucht. Haben die meisten Menschen hier nicht nichts zu tun? Sie schreiben die Terminal-Standardfunktionalität für mql5 um. Vielleicht schreibt ja bald jemand ein ganzes Terminal über mql5.
Wenn es unter realen Bedingungen zu einer Rücksetzung und Neuberechnung des Indikators kommt, ist das nicht weiter schlimm.
Eine weitere Frage ist aufgetaucht. Haben die meisten Menschen hier nicht nichts zu tun? Sie schreiben die Terminal-Standardfunktionalität für mql5 um. Vielleicht wird bald jemand ein ganzes Terminal über mql5 schreiben.
Natürlich ist das nicht so schlimm. Wenn Sie 100 ZUP in einem Terminal haben (nur als Beispiel), ist das kein Problem...
Die gleiche Frage wurde gestellt. Jeder spricht gerne nur aus seiner Sicht, warum?
Hier gibt es mehr als einen Indikator:
Der Einfluss der Standardfunktion IndicatorCount ist dafür einfach tödlich (ich habe es persönlich überprüft). Und wenn sie als Klassen implementiert werden, sind die Kommunikationsunterbrechungen sogar lila
P.S. Für einen MA ist es natürlich keine große Sache
Natürlich ist das keine große Sache. Wenn Sie 100 ZUPs in einem Terminal haben (nur um ein Beispiel zu nennen), ist das keine große Sache...
Die gleiche Frage hat sich gestellt. Jeder argumentiert gerne nur von seinem eigenen Glockenturm aus, warum?
Irgendjemand will immer mehr, als er bewältigen kann. Aber warum so viele?
Das Problem des Zurücksetzens des Indikators kann mit fünf Zeilen Code gelöst werden. Erinnern Sie sich an die Zeit des ersten Taktes, wenn sie sich geändert hat, müssen Sie eine vollständige Neuberechnung vornehmen. Speichern Sie die Nummer des letzten Balkens, im Falle eines Rücksetzens setzen Sie die Neuberechnung ab diesem Balken fort und das war's.
Ich habe keine Angst, von meinem eigenen Glockenturm aus zu sagen, ohne irgendetwas mit Argumenten zu bestätigen, dass mein Glockenturm richtig ist, Punkt.
Irgendjemand will immer mehr, als er bewältigen kann. Aber warum so viel?
Sie können das Problem des Zurücksetzens des Indikators mit fünf Zeilen Code umgehen. Erinnern Sie sich an die Zeit des ersten Taktes, wenn sie sich geändert hat, ist eine vollständige Neuberechnung erforderlich. Speichern Sie die Nummer des letzten Balkens, im Falle eines Rücksetzens setzen Sie die Neuberechnung ab diesem Balken fort und das war's.
Ich habe keine Angst, von meinem Glockenturm aus zu sagen, ohne irgendetwas mit Argumenten zu bestätigen, dass mein Glockenturm richtig ist und das war's.
Seien Sie nicht so selbstgerecht. Lernen Sie, nicht nur zuzuhören, sondern anderen zuzuhören.
Die Geschichte kann sich in der Mitte ändern, und Ihr Ansatz wird in die Brüche gehen. Fragen Sie Renat danach.
Der Fehler in IndicatorCounted() in MT4, der erst jetzt mit meinem Tipp behoben wurde, schickte auch korrekt geschriebene Indikatoren zum Schrott (insbesondere ZigZag auf kleinen TFs).
Ganz zu schweigen von Ihrer Vorgehensweise in diesem Fall....
Ich werde nicht einmal mit Ihnen streiten, weil Sie in dieser Situation völlig falsch liegen.
Seien Sie nicht so selbstbewusst in Bezug auf sich selbst. Lernen Sie nicht nur zuzuhören, sondern auch, anderen zuzuhören.
Die Geschichte kann sich in der Mitte ändern und Ihr Ansatz wird in die Brüche gehen. Fragen Sie Renat danach.
Der Fehler in IndicatorCounted() in MT4, der erst jetzt durch meinen Tipp korrigiert wurde, hat selbst korrekt geschriebene Indikatoren in den Müll geschickt (insbesondere ZigZag auf kleinen TF).
Ich werde mich nicht einmal mit Ihnen streiten, denn Sie liegen in dieser Situation völlig falsch.
Fügen Sie einige weitere Prüfungen zum Zeitpunkt des Zurücksetzens hinzu, um festzustellen, ob sich die Anzahl der Takte erhöht hat, aber die Taktzeit sich nicht geändert hat, oder ob mehr als ein Takt hinzugefügt worden ist.
Was die Selbstüberschätzung angeht, so ist es genau umgekehrt, du bist der Übermütige, du bist der Dritte, der sich für cooler hält als MQ.
Fügen Sie einige weitere Prüfungen zum Zeitpunkt des Zurücksetzens hinzu, ob sich die Anzahl der Takte erhöht hat, aber die Taktzeit sich nicht geändert hat, oder ob mehr als ein Takt hinzugefügt wurde.
Was das Selbstvertrauen angeht, so ist es genau umgekehrt, ihr seid hier alle die Übermütigen, du bist der Dritte, der sich für cooler hält als MQ.
Welche Art von Schecks? Situation. Auf dem alten Balken erscheint ein neues Häkchen. Es hat sich nichts geändert - weder die Gesamtzahl der Takte noch der Zeitpunkt, zu dem der letzte Takt geöffnet wurde, aber gleichzeitig
die letzten 30 Balken wurden umgeschrieben (ihre Eröffnungs-/Schlusskurse, Höchst- und Mindestwerte haben sich geändert, wenn auch nur unwesentlich).
Was werden Sie mit Ihrem Algorithmus machen? Nichts! Das wird in dieser Situation einfach nicht funktionieren. Und der Indikator wird völlig falsch sein!
Was in MT4 vor den letzten Builds war - in 70% der Fälle würde es nicht auf diese Situation reagieren.
Aber nach einer Analyse des Problems wurde es behoben. Stingo schrieb darüber: https://www.mql5.com/ru/forum/132422
Ich glaube nicht, dass ich cooler bin als andere. Im Gegenteil, ich helfe aktiv mit, alle Fehler in MT4 und MT5 zu beheben - fragen Sie einen Vertreter von MetaQuotes.
Und die Tatsache, dass einige Mechanismen nicht so umgesetzt werden, wie Sie es wünschen - man kann es nicht allen recht machen....
Es ist eine interessante Frage, was richtig ist, das, was vor oder das, was nach der Geschichtskorrektur war. Wenn Sie nicht zu den korrigierten Balken zurückgehen, arbeitet der Indikator weiter, als ob der Verlauf nicht korrigiert worden wäre. Hrenfx hat genau diese Einstellung, er hält die alte Geschichte für richtig, Sie haben das Gegenteil.
Es gibt auch die Meinung, dass man nur regulär prev_calculated verwenden sollte, ohne Variationen. Wenn der Indikator schwer ist, begrenzen Sie die Anzahl der beim Start gezählten Balken. Der Rest ist ein Tamburintanz, das Ergebnis ist zweifelhaft.
Es ist eine interessante Frage, was richtig ist, das, was vor oder das, was nach der Geschichtskorrektur war. Wenn Sie nicht zu den korrigierten Balken zurückgehen, arbeitet der Indikator weiter, als ob der Verlauf nicht korrigiert worden wäre. Hrenfx hat genau diese Einstellung, er hält die alte Geschichte für richtig, Sie haben das Gegenteil.
Es gibt auch die Meinung, dass man nur das reguläre prev_calculated verwenden sollte, und zwar unveränderlich. Wenn der Indikator schwer ist, begrenzen Sie die Anzahl der beim Start gezählten Balken. Der Rest tanzt mit Tamburin, das Ergebnis ist zweifelhaft.
Jeder entscheidet für sich selbst, was er für richtig hält und was nicht. Für ZigZag ist die oben beschriebene Situation absolut tödlich. Für MA gibt es eine Abweichung von 0,0001 in seinem Wert...
Meinungen können oft aufgezwungen werden (ich sage nicht, dass sie falsch sind).
Generell schlage ich vor, die Diskussion hier zu beenden. Theoretische Überlegungen bringen Sie nicht weiter.
Im Testprogramm funktioniert die benutzerdefinierte Optimierung der Indikatorberechnungen perfekt, aber im Client-Terminal kann es zu unangenehmen Verschiebungen des Verlaufs und falschen Berechnungen kommen.
Übrigens verwendet mt5 eine sehr effektive und sofortige Kontrolle der Integrität der historischen Basis in rltime, was die Häufigkeit des Zurücksetzens von prev_counted auf Null erhöht. Wenn Sie diesen Zähler nicht richtig berücksichtigen und Ihre eigenen Optimierungen vornehmen, können Sie sich in der Praxis eine Menge Probleme einfangen. Aktualisierungen des Minutenverlaufs werden vom Server selbst sofort an die Terminals übermittelt.
Im Testgerät funktioniert die benutzerdefinierte Optimierung der Indikatorberechnungen einwandfrei, aber im Client-Terminal verschiebt sich der Verlauf und es kann zu falschen Berechnungen kommen.
Das ist es, was ich meine.
Vielleicht denken Sie darüber nach, wie prev_counted nicht auf Null, sondern auf den ersten unveränderten Wert zurückgesetzt werden kann?