Das perfekte mechanische Handelssystem. - Seite 4
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
Bisher scheint mir alles viel einfacher zu sein. Sie sollten mit einem einfachen, naiven System mit einem Minimum an Abstimmungsparametern beginnen und einen Block mit adaptiven Parameteränderungen in Echtzeit hinzufügen...
Das war's, es ist nur noch sehr wenig übrig :) Wir müssen entscheiden, welche Daten wir für die Berechnung der adaptiven Parameter verwenden wollen. Ich weiß nicht einmal, was ich vorschlagen soll :(
Hat jemand eine Idee in dieser Hinsicht?
Zunächst kann ich das folgende TZ-Modell vorschlagen:
Wir nehmen einen einfachen Expert Advisor und schreiben dazu einen Block "Tester" (dessen Aufgabe es sein wird - einmal am Tag, z.B. um 01:00 GMT, TS unter der monatlichen Geschichte anzupassen).
xeon kann das Prüfgerät so eingestellt werden, dass es immer funktioniert. Natürlich müsste es in hochoptimiertem C geschrieben werden, nicht in mql4. Leider gibt es bei all dem einen sehr ernsten Fallstrick. Es handelt sich dabei um den Zeitraum der Schätzung und Optimierung des Systems. D.h. für wie lange soll die Leistung bewertet werden? Nehmen wir an, es gibt zwei Strategien, die um das Recht auf echten Handel konkurrieren. Die erfolgreiche aktuelle und die schlechteste. Innerhalb einer Stunde hat zum Beispiel die aktuelle Strategie Geld verloren, während die Backup-Strategie im Gegenteil erfolgreich war. Die Frage ist: Strategien ändern oder nicht ändern? Schließlich kann dies der Beginn eines neuen Trends sein (nicht zu verwechseln mit Trend/Flit!), oder auch zufällig. D.h. es stellt sich heraus, dass ein solches Prüfgerät selbst mindestens einen (und wichtigen !!!) konfigurierbaren Parameter hätte - die Auswertungs- und Optimierungsdauer. Verstehen Sie nicht, dass ich damit sagen will, dass ein solcher Ansatz unmöglich ist. Ich will damit nur sagen, dass es bei all dem Schwierigkeiten und undurchsichtige Stellen gibt.
Versuchen wir es doch einmal mit einem einfachen Ansatz.
Die Aufgabe: Ist es möglich, eine Funktion zu schreiben, die den monatlichen Verlauf einmal am Tag durchläuft und die optimale Zahl für den Stop-Loss-Parameter festlegt?
UND DAS GRÖSSTE: Kann ich diese Funktion nutzen, um den Tester zu überprüfen? Wird der Tester überhaupt funktionieren? Es stellt sich heraus, dass es jeden Tag im Testmodus den Parameter der Haltestelle für einen neuen Tag ändern sollte? Ist das möglich? Wenn diese Aufgabe gelöst ist, ist der Rest, wie bereits gesagt, nur noch Zuckerguss.
xeon kann das Prüfgerät so eingestellt werden, dass es immer funktioniert. Natürlich müsste es in hochoptimiertem C geschrieben werden, nicht in mql4. Leider gibt es bei all dem einen sehr ernsten Fallstrick. Es handelt sich dabei um den Zeitraum der Schätzung und Optimierung des Systems. D.h. für wie lange soll die Leistung bewertet werden? Nehmen wir an, es gibt zwei Strategien, die um das Recht auf echten Handel konkurrieren. Die erfolgreiche aktuelle und die schlechteste. Innerhalb einer Stunde hat zum Beispiel die aktuelle Strategie Geld verloren, während die Backup-Strategie im Gegenteil erfolgreich war. Die Frage ist: Strategien ändern oder nicht ändern? Schließlich kann dies der Beginn eines neuen Trends sein (nicht zu verwechseln mit Trend/Flit!), oder auch zufällig. D.h. es stellt sich heraus, dass ein solches Prüfgerät selbst mindestens einen (und wichtigen !!!) konfigurierbaren Parameter hätte - die Auswertungs- und Optimierungsdauer. Verstehen Sie mich nicht falsch, wenn ich sage, dass ein solcher Ansatz unmöglich ist. Ich will damit nur sagen, dass es bei all dem Schwierigkeiten und undurchsichtige Stellen gibt.
Versuchen wir es doch einmal mit einem einfachen Ansatz.
Die Aufgabe: Ist es möglich, eine Funktion zu schreiben, die den monatlichen Verlauf einmal am Tag durchläuft und die optimale Zahl für den Stop-Loss-Parameter festlegt?
UND DAS GRÖSSTE: Kann ich diese Funktion nutzen, um den Tester zu überprüfen? Wird der Tester überhaupt funktionieren? Es stellt sich heraus, dass es jeden Tag im Testmodus den Parameter der Haltestelle für einen neuen Tag ändern sollte? Ist das möglich? Wenn Sie dieses Problem lösen, ist der Rest wie gesagt nur noch Zuckerguss.
Soweit ich weiß, ist es möglich, eine solche Funktion in mql zu schreiben, aber diese Aufgabe ist nicht einfach für mich, weil ich ein "Amateur-Programmierer" bin und ich brauche Zeit, um es zu tun.
Selbsteinstellende Indikatoren sind eine Sackgasse. Ich werde versuchen, meine Meinung zu begründen.
Ich habe mehrere solcher Indikatoren entwickelt, aber sie schienen empfindlich auf die Volatilität der von verschiedenen Maklerunternehmen stammenden Notierungen zu reagieren. Das heißt, diese Indikatoren funktionieren gut mit den Daten eines Maklerunternehmens und überhaupt nicht mit den Daten eines anderen. Am schlimmsten ist, dass sie mit TK-Daten arbeiten. Zum Beispiel gibt es bei den Standardindikatoren für dasselbe Kursintervall bei einem Maklerunternehmen eine Abweichung, bei einem anderen nicht.
Meine Untersuchungen haben gezeigt, dass die Volatilität der wichtigste Faktor ist, der bei einem selbsteinstellenden Indikator berücksichtigt werden muss. Allerdings ist der Indikator letztendlich von der Filtermethode der Notierungen in den verschiedenen Maklerunternehmen und von den Änderungen dieser Methode (die von den Maklerunternehmen nicht mitgeteilt werden) abhängig.
Hier bin ich auch mit der Tatsache konfrontiert, dass ich die Selbstoptimierung nicht "härten" kann (wie Renat immer sagt), weil sie konstant (linear) und nicht diskret ist.
Meiner Meinung nach lässt sich das Problem der Volatilität nur dadurch vermeiden, dass man die absoluten Werte von Indikatoren und Kursen ignoriert. D.h. um eine Entscheidung in MTS zu treffen, sollten wir die Korrelation von Werten in der einen oder anderen Form nutzen, und das ist im Wesentlichen Mustererkennung.
es!
Selbsteinstellende Indikatoren sind eine Sackgasse. Ich werde versuchen, meine Meinung zu begründen.
Ich habe mehrere solcher Indikatoren entwickelt, aber sie schienen empfindlich auf die Volatilität der von verschiedenen Maklerunternehmen stammenden Notierungen zu reagieren. Das heißt, diese Indikatoren funktionieren gut mit den Daten eines Maklerunternehmens und überhaupt nicht mit den Daten eines anderen. Am schlimmsten ist, dass sie mit TK-Daten arbeiten. Zum Beispiel gibt es bei den Standardindikatoren für dasselbe Kursintervall bei einem Maklerunternehmen eine Abweichung, bei einem anderen nicht.
Meine Untersuchungen haben gezeigt, dass die Volatilität der wichtigste Faktor ist, der bei einem selbsteinstellenden Indikator berücksichtigt werden muss. Der Indikator ist jedoch von der Art und Weise abhängig, wie die Kurse in den verschiedenen Maklerunternehmen gefiltert werden, und von den Änderungen dieser Methode (die von den Maklerunternehmen nicht mitgeteilt werden).
Hier bin ich auch mit der Tatsache konfrontiert, dass ich die Selbstoptimierung nicht "härten" kann (wie Renat immer sagt), weil sie konstant (linear) und nicht diskret ist.
Meiner Meinung nach lässt sich das Problem der Volatilität nur dadurch vermeiden, dass man die absoluten Werte von Indikatoren und Kursen ignoriert. D.h. um eine Entscheidung in MTS zu treffen, sollten wir die Korrelation von Werten in der einen oder anderen Form nutzen, und das ist im Wesentlichen Mustererkennung.
Bei jedem System kommt es nicht auf den Wert des Preises an, sondern auf die Geschwindigkeit der Preisänderung (manchmal nur auf das Vorzeichen).
Manchmal wird die Preisbeschleunigung verwendet (Schätzung der auf den Preis wirkenden Kraft als Frühindikator).
ALLE Blinker, die mit MTS verwendet werden, sind dazu gedacht, die Geschwindigkeit zu schätzen.
Unterschiedliche Indikatoren sind einfach unterschiedliche MÖGLICHKEITEN zur Einschätzung der Geschwindigkeit.
1. ALLE Oszillatoren schätzen die Geschwindigkeit, manchmal auch die Beschleunigung (wie der MACD).
2. ALLE gleitenden Durchschnitte werden NIEMALS für sich allein verwendet,
nur im Vergleich zu anderen gleitenden Durchschnitten (Preis ist ein gleitender Durchschnitt mit Länge = 1).
Dieser Vergleich der gleitenden Durchschnitte (eigentlich der Vergleich ihrer Differenz mit Null) ist ein Oszillator.
3. Nicht der Preis ist zu berücksichtigen, sondern der Logarithmus des Preises.
Mit Logarithmen wird alles einfacher und richtiger.
Bei kleinen Preisveränderungen macht es keinen Unterschied, ob man mit dem Preis oder dem Logarithmus arbeitet,
Bei großen Preisänderungen wird der Unterschied erheblich sein.
Darf ich Ihnen einen kleinen Tipp geben? :)
Bei jedem System kommt es nicht auf den Wert des Preises an, sondern auf die Geschwindigkeit der Preisänderung (manchmal nur auf das Vorzeichen).
Manchmal wird die Preisbeschleunigung verwendet (Schätzung der auf den Preis wirkenden Kraft als Frühindikator).
ALLE Blinker, die mit MTS verwendet werden, sind dazu gedacht, die Geschwindigkeit zu schätzen.
Unterschiedliche Indikatoren sind einfach unterschiedliche MÖGLICHKEITEN zur Einschätzung der Geschwindigkeit.
1. ALLE Oszillatoren schätzen die Geschwindigkeit, manchmal auch die Beschleunigung (wie der MACD).
2. ALLE gleitenden Durchschnitte werden NIEMALS für sich allein verwendet,
nur im Vergleich zu anderen gleitenden Durchschnitten (Preis ist ein gleitender Durchschnitt mit Länge = 1).
Dieser Vergleich der gleitenden Durchschnitte (eigentlich der Vergleich ihrer Differenz mit Null) ist ein Oszillator.
3. Nicht der Preis ist zu berücksichtigen, sondern der Logarithmus des Preises.
Mit Logarithmen wird alles einfacher und richtiger.
Bei kleinen Preisveränderungen macht es keinen Unterschied, ob man mit dem Preis oder dem Logarithmus arbeitet,
bei großen Preisänderungen wird der Unterschied erheblich sein.
Oder möchten Sie sich vielleicht auch an der Erstellung des Codes beteiligen? :-), mit Ihrer Programmiererfahrung würde es viel schneller gehen!