Vergleich von gleitendem Durchschnitt (und anderen Indikatoren) und Fehler - Seite 2
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 hat im Prinzip nichts mit mql zu tun. Nehmen wir eine abstrakte Programmiersprache. In dem von mir angeführten Beispiel besteht das Hauptproblem darin, dass die Werte für die Differenz der Muwings in ein und demselben Balken nicht gleich sind (2e-16 in der ersten Berechnung und genau 0 in der zweiten). In diesem Fall darf dieser Schnittpunkt in keiner Weise bestimmt werden. Wenn wir zu mql zurückkehren, bedeutet Normalisierung, dass die Zahl gerundet wird(oder besser gesagt, dass einfach alle Zahlen nach einem bestimmten Vorzeichen weggelassen werden, wie in der Sish-Funktion floor, aber auf eine bestimmte Dezimalstelle). Woher weiß ich also, auf welche Ziffer ich normalisieren muss? Wenn die falsche Ziffer gewählt wird, können alle Werte IMMER auf genau 0 gerundet werden. Die Normalisierung ist hier also gefährlich und löst das Problem im Allgemeinen nicht.
Zu dem, was Alexey Lebedev geschrieben hat. Ja, ich habe in diese Richtung gedacht. Wenn wir jedoch beide Differenzen um mehr oder gleich 0 vergleichen, besteht die Wahrscheinlichkeit, dass wir ein falsches Signal erhalten (z. B. die theoretisch mögliche Situation, dass die Muwings zwischen benachbarten Balken genau die gleichen Werte haben). Dann ändert ihre Differenz das Vorzeichen nicht (es gibt keine Kreuzung), aber das Signal für die Kreuzung wird programmatisch bestimmt. Sie könnten, wie Sie vorgeschlagen haben, nur einen Vergleich auf mehr oder gleich setzen. Aber dann ist das Problem, dass in der Berechnung in dieser Situation zunächst wird es nicht gleich 0 (2e-16), und auf der nächsten Bar wird es genau 0, aber es wird eine strenge Vergleich sein.
Es ist wichtig zu verstehen, warum die gleiche Differenz, wenn sie auf verschiedenen Balken berechnet wird, NICHT das gleiche Ergebnis ergibt. Wenn das Ergebnis dasselbe wäre, würde das Problem immer durch die Einführung eines nicht strengen Vergleichs gelöst.
Bei der Normalisierung wird auf eine bestimmte Dezimalstelle gerundet. Nicht alle Zahlen nach einem bestimmten Vorzeichen werden verworfen , sondern es wird gerundet.
Wenn ich Sie in diesem Zusammenhang richtig verstehe (ich nehme sowohl Ihren ersten Beitrag mit Screenshot als auch Ihren zweiten), können Ihnen verschiedene Experimente mit einer solchen Methode, einschließlich der Berücksichtigung von DoubleToString beim Ausdrucken, noch helfen, nehme ich an. Rosomah hat es Ihnen gegenüber vor mir erwähnt .
Einschließlich, helfen, für sich selbst zu bestimmen, auf welche Zahl zu normalisieren bei allen Aufgaben, oder ob in einigen Fällen Normalisierung erforderlich ist (in Fällen von Zweifeln, die Anwendung oder nicht auf die Menge der damit verbundenen Faktoren, einschließlich, dass das Programm dann in verschiedenen DC angewendet werden können und folglich die berechneten Werte können unterschiedlich sein).
Meiner Meinung nach besteht die Gefahr, Signale zu erhalten, die je nach Aufgabe als falsch angesehen werden können, nur dann, wenn die Normalisierung nicht angewandt wird (oder wenn es aufgrund eines kleinen Wertes keinen ersten Vergleich gibt), wo dies kein Problem darstellen würde.
Wenn DoubleToString im Ausdruck nicht angewandt wird, kann es außerdem zu dem Missverständnis kommen, dass die gleiche Differenz oder die gleichen Werte nicht das gleiche Ergebnis sind.
/* Nur für den Fall, dass ich noch einmal erwähnen möchte, dass es beim Ausdruck von Zahlen vom Typ Double notwendig ist, DoubleToString zu verwenden, da die Ausgabe einen numerischen Wert in einen Textwert umwandelt. Wenn diese Funktion nicht verwendet wird, können daher Fehler angezeigt werden, die eigentlich gar nicht vorhanden sind.
Die Anzahl der Nachkommastellen in dieser Funktion ist natürlich nicht geringer als die Anzahl der Nachkommastellen bei den normierten Werten. Und bei nicht normalisierten Werten ist die Anzahl der Dezimalstellen größer.
Die Berechnung der iMA-Funktion ist höchstwahrscheinlich optimiert. Erster Wert = Summe(Abschluss)/N, zweiter Wert = vorheriger Wert des MA+(neuer Abschluss-alter Abschluss)/N.
Also können iMAs im Allgemeinen für ein und denselben Balken unterschiedliche Werte der beiden Muwings zu verschiedenen Aufrufzeiten liefern?
Bei der Normalisierung wird auf die angegebene Dezimalstelle gerundet. Es handelt sich um eine Rundung und nicht darum, alle Zahlen nach einer bestimmten Dezimalstelle zu verwerfen.
Wenn ich Sie genau in dem Zusammenhang verstehe, den Sie meinen (ich berücksichtige sowohl Ihren ersten Beitrag mit Screenshot als auch Ihren zweiten Beitrag), dann können Ihnen verschiedene Experimente mit einer solchen Methode, einschließlich der Berücksichtigung von DoubleToString beim Ausdrucken, glaube ich, noch helfen.
Einschließlich, helfen, für sich selbst zu definieren, auf welche Zahl zu normalisieren bei allen Aufgaben, oder ob die Normalisierung ist in einigen Fällen erforderlich (in Zweifelsfällen, verwenden oder nicht verwenden, auf eine Reihe von begleitenden Faktoren, einschließlich, dass Programm kann dann in verschiedenen DC angewendet werden und, bzw., erhaltenen Werte Berechnung kann unterschiedlich sein).
Meiner Meinung nach besteht die Gefahr, Signale zu erhalten, die je nach Aufgabe als falsch angesehen werden könnten, nur dann, wenn die Normalisierung nicht angewandt wird (oder wenn die erste Methode aufgrund eines kleinen Wertes nicht verglichen wird), wo es nicht schaden würde.
Wenn DoubleToString nicht auf den Ausdruck angewandt wird, kann es außerdem zu dem Missverständnis kommen, dass die gleiche Differenz oder die gleichen Werte nicht das gleiche Ergebnis sind.
/* Nur für den Fall, dass ich noch einmal erwähnen möchte, dass es beim Ausdruck von Zahlen vom Typ Double notwendig ist, DoubleToString zu verwenden, da die Druckausgabe einen numerischen Wert in einen Textwert umwandelt. Wenn diese Funktion nicht verwendet wird, können folgende Fehler auftreten
Die Anzahl der Nachkommastellen in dieser Funktion ist natürlich nicht geringer als die Anzahl der Nachkommastellen bei den normierten Werten. Und bei nicht normalisierten Werten ist die Anzahl der Dezimalstellen größer.
Es ist klar, dass die letzte signifikante Ziffer gerundet wird. Wenn man aber zum Beispiel 5 signifikante Stellen für die Zahl 0,000016 einsetzt, wird sie 0,00002 sein, und wenn es weniger signifikante Stellen gibt, wird sie immer 0 sein. Eine Rundung auf eine bestimmte Ziffer ist daher nicht immer möglich. Die MA-Werte hängen nicht nur vom Zeitrahmen ab, sondern auch von den Balken selbst. Daher ist nicht klar, wie die Anzahl der signifikanten Stellen während der Normalisierung im allgemeinen Fall festgelegt werden kann.
Was ich am Infinitesimalwert nicht verstehe, ist, wie man ihn anwenden kann. Infinitesimal (Fehler) wird verwendet, um eine reelle Zahl mit 0 zu vergleichen. Ich hingegen muss den Unterschied vergleichen. Hier könnte die Situation noch schlimmer sein. Ich habe zum Beispiel etwas Epsilon eingestellt. Wenn die Differenz größer als Epsilon ist, betrachte ich sie als positiv. Wenn er kleiner als minus Epsilon ist, ist er negativ. Wenn sie innerhalb der Grenzen liegt, ist sie 0. Aber wie bestimmt man dann den Wechsel des Vorzeichens der Differenz? Zum Beispiel liegt die Differenz der Muvings auf zwei Balken innerhalb von Epsilon. Aber im ersten Fall ist sie positiv, im zweiten negativ (d.h. die Kreuzung ist bereits erfolgt). Und I wird unter Berücksichtigung der Einführung von Fehlern die Differenz als 0 betrachten. Dann sollte die Bedingung für den Vorzeichenwechsel geändert werden. Das Signal zweier MA, die sich von oben nach unten kreuzen, ist in diesem Fall sowohl ein einfacher Vergleich von <0 (war) und >0 (wurde) als auch von =0 (war) und >0 (wurde). Und was am wichtigsten ist: In dem beschriebenen Fall (wenn die Werte am gleichen Punkt bei verschiedenen Aufrufen unterschiedlich sind) hilft die Einführung dieses Fehlers nicht. Dieser Unterschied kann immer so groß sein, dass man, egal welches Epsilon man wählt, kein Signal erhält.
Es ist klar, dass die letzte signifikante Ziffer gerundet wird. Wenn Sie aber z. B. für eine Zahl 0,000016 eine Normalisierung mit 5 Ziffern vornehmen, wird es die Zahl 0,00002 sein, und wenn es weniger Ziffern sind, wird es immer 0 sein. Eine Rundung auf eine bestimmte Ziffer ist daher nicht immer möglich. Die MA-Werte hängen nicht nur vom Zeitrahmen ab, sondern auch von den Balken selbst. Daher ist nicht klar, wie die Anzahl der signifikanten Stellen während der Normalisierung im allgemeinen Fall festgelegt werden kann.
Was ich am Infinitesimalwert nicht verstehe, ist, wie man ihn anwenden kann. Infinitesimal (Fehler) wird verwendet, um eine reelle Zahl mit 0 zu vergleichen. Ich hingegen muss den Unterschied vergleichen. Hier könnte die Situation noch schlimmer sein. Ich habe zum Beispiel etwas Epsilon eingestellt. Wenn die Differenz größer als Epsilon ist, betrachte ich sie als positiv. Wenn er kleiner als minus Epsilon ist, ist er negativ. Wenn sie innerhalb der Grenzen liegt, ist sie 0. Aber wie bestimmt man dann den Wechsel des Vorzeichens der Differenz? Zum Beispiel liegt die Differenz der Muvings auf zwei Balken innerhalb von Epsilon. Aber im ersten Fall ist sie positiv, im zweiten negativ (d.h. die Kreuzung ist bereits erfolgt). Und I wird unter Berücksichtigung der Einführung des Fehlers die Differenz als 0 betrachten. Dann sollte die Bedingung des Vorzeichenwechsels geändert werden. Das Signal zweier MA, die sich von oben nach unten kreuzen, ist in diesem Fall sowohl ein einfacher Vergleich von <0 (war) und >0 (wurde) als auch von =0 (war) und >0 (wurde). Und was am wichtigsten ist: In dem beschriebenen Fall (wenn die Werte am gleichen Punkt bei verschiedenen Aufrufen unterschiedlich sind) hilft die Einführung dieses Fehlers nicht. Dieser Unterschied kann immer so groß sein, dass Sie, egal welches Epsilon Sie wählen, kein Signal erhalten.
Ich denke, dass man sich beim Lösen bestimmter Aufgaben auch auf die Genauigkeit der signifikanten Dezimalstellen verlassen kann. Beim Doppelten sind es laut Dokumentation 15 signifikante Ziffern. Das Format der Normalisierungsgenauigkeit, von 0 bis 8, gemäß der Dokumentation. DoubleToString hat seine eigenen Besonderheiten bei den Genauigkeitsformaten.
Außerdem ist iMA aus meiner Sicht eine Funktion, die berücksichtigt, dass die damit abgeleiteten Werte in verschiedenen Situationen und zur Lösung verschiedener Probleme eingesetzt werden. Dementsprechend können die von ihm ausgegebenen Werte unterschiedlich verarbeitet werden, auch im Hinblick auf bestimmte Aufgaben.
Darüber hinaus ist die Berechnung von Durchschnittswerten eine mathematische Berechnung. Zum Beispiel: (1.20525 + 1.20598 + 1.2081)/3 = 1.2064433333... Dementsprechend erhöhen berechnete Werte mit kleinen oder erweiterten Rundungen die Möglichkeiten zur Anwendung der Berechnungen.
Für den Fall der Fälle möchte ich erwähnen, dass Sie anstelle von iMA auch die Funktionen der MovingAverages-Bibliothek verwenden können, die im Standard-Terminalpaket enthalten ist. Sie können aber auch Ihre eigenen Funktionen verwenden, die auf den Funktionen dieser Bibliothek basieren.
/* In mathematischen Berechnungen kann esBesonderheiten bei der Arbeit mit Zahlen vom Typ double geben */.
Bei den Epsilons hingegen werde ich passen.
P./S.: Ich denke, Experimente können Ihnen helfen. Theoretische Überlegungen ohne praktische Experimente (mit großen Datenmengen) für bestimmte Aufgaben können verwirren und von akzeptablen Lösungen ablenken.
Dina Paches:
...
Was für ein Chaos. Wir vergleichen die MAs seit 300 Tagen... Normalisieren Sie sich auf die Ziffern und machen Sie sich keine Mühe...
Sie können die Werte direkt normalisieren (die Differenz - auf keinen Fall). Aber auch hier muss der vorgegebene ala Benchmark-Code für den Vergleich von MA geändert werden und man sollte sowieso eine nicht-strikte Ungleichung eingeben. Außerdem bleibt die Frage der unterschiedlichen MA-Werte auf ein und demselben Balken, wenn sie zu verschiedenen Zeiten berechnet werden, offen. Wenn es sich weiter wiederholt, ist es nicht sicher, dass selbst die Normalisierung und die Einführung einer nicht-strikten Ungleichung das Problem vollständig lösen wird. Auch den Fall, dass sich die Muwings innerhalb eines Balkens zweimal überschneiden, können Sie nicht erfassen, wenn Sie nicht nach Ticks, sondern nach der Eröffnung eines neuen Balkens analysieren. Vielleicht können Sie Ihre Erfahrungen mitteilen, wie Sie sich in dieser Situation verhalten?
Nun, erstens ergibt die Differenz zweier normalisierter Werte letztendlich einen nicht normalisierten Wert. Sie müssen die normalisierte Differenz überprüfen.
Zweitens, wenn Sie Crossovers innerhalb eines Balkens abfangen wollen, nehmen Sie die Werte aller Ticks auf dem Nullpunkt und dem ersten Balken - Sie werden eine Menge abfangen ... ...nur aufpassen ...
Wenn Sie nach der Eröffnung eines Balkens testen, sollte der Expert Advisor die Eröffnung eines neuen Balkens eindeutig überwachen und im Nachhinein auf Überkreuzungen prüfen.
Entscheiden Sie zunächst selbst, ob Sie zum Zeitpunkt der Bareröffnung oder bei jedem Tick handeln möchten, und schreiben Sie dann Ihren Code. Und dementsprechend testen Sie es auch auf diese Weise.
Dina, ich bin erstaunt über deine engelhafte Geduld ...
Danke, Artem, aber leider hat sich herausgestellt, dass es auch Grenzen haben kann.