INVESTOX-Forum

Hallo Bernd 2,

ich denke, es ist wichtig, in der Diskussion zwischen Systementwicklung und laufender Systemwartung/Optimierung zu unterscheiden.

Ich entwickle meine HS inzwischen ausschließlich auf Basis möglichst langer Historien.

Erst seit ich dazu übergegangen bin, erreiche ich bei meinen 60-Minuten Intraday Handelssystemen lange reale Nachlaufzeiten (> 1 Jahr), wenn die Systeme überhaupt nicht optimiert werden. Die Systeme antizipierten außerdem bisher auch Änderungen im Marktverhalten gut (wie z.B. die Handelszeitverlängerung vom letzten Jahr).

Vorher habe ich meine Systeme an „kurzen“ Intraday-Historien entwickelt – i.e. maximal 3-4 Jahre Kursdaten. Dieser früheren Vorgehensweise lag primär die Überlegung zugrunde, dass ältere Intraday-Historien die aktuelle Marktsituation nicht mehr repräsentieren und deshalb für die Systementwicklung nutzlos sind.
Das hatte ich in diversen Fachbüchern hochkarätiger Systementwickler so gelesen,und ich habe zunächst keinen Grund gesehen, diese Aussagen anzuzweifeln.

In der Praxis musste ich dann aber feststellen, dass die auf Basis der kurzen Historien entwickelten Systeme alle nur sehr geringe Nachlaufzeiten hatten. Oft liefen die Systeme nur nur einige wenige Wochen einigermaßen profitabel weiter, bevor sie neu optimiert werden mussten. Wenn überhaupt…..
Optimierte man sie nicht, stürzten die KK mit schöner Regelmäßigkeit ab.

An diesem Punkt meiner „Systementwickler-Karriere“ habe ich mich ernsthaft gefragt, warum ich eigentlich überhaupt so einen Aufwand für das ganze Backtesting betreibe …..wo doch die Ergebnisse im Realzeitraum praktisch nie etwas mit dem Backtests zu tun hatten.

Andererseits wusste ich sicher, dass so gut wie alle erfolgreichen Systemtrader auf irgendeine Art und Weise Backtests durchführen….
Ich nahm dann damals an, deren Backtests müssten irgendwie aussagekräftiger sein als meine …. sonst wären die erfolgreichen Systementwickler auch längst wieder vom Backtesting weg.

Neben diversen anderen Änderungen meiner Vorgehensweise bei Systementwicklungen entwickelte ich in der Folgezeit auf Basis langer Historien und ich nahm zusätzlich noch verschiedene Modifikationen der langen Historien (Bereinigungen, Zeitbegrenzungen etc.) vor.
Außerdem teste ich die Systeme an Historien aus verschiedenen Datenquellen.

Durch all diese Maßnahmen wurde meine Datenbasis für die Systementwicklung deutlich vergrößert.

Meine Erfahrung nach diesen Modifikation:
Keines der so entwickelten Intraday-Handelssysteme (….und das sind bei mir inzwischen einige…) ist mir mehr abgestürzt.

Die Systeme haben sich im Realzeitraum bisher ausnahmslos alle so verhalten, wie auch während der Backtests. Das älteste dieser Systeme ist inzwischen knapp 1 ½ Jahre alt ….und markierte erst Mitte Oktober 2006 wieder ein neues KK-Hoch...bei wie gesagt komplett unveränderten Einstellungen.
Es gibt derzeit noch keine Hinweise darauf, dass diese Systeme schwächeln.
Ich denke, irgendwann werden auch sie optimiert werden müssen – aber wann das sein wird, kann ich bisher noch nicht einschätzen.

Die Backtests an Kursdaten der Vergangenheit waren demnach aussagekräftig für das Systemverhalten der Zukunft.

Man konnte die an den langen Historien gebacktesteten Systeme real traden, indem man sie komplett unverändert an das ORM gehängt hat.
In diesem Fall hätte man aber Lateralphasen und Drawdowns wie im Backtest akzeptieren müssen.

Die Systeme wurden alle so entwickelt, dass sie mit einer einzigen Einstellung der Optimierungsvariablen während des gesamten Backtestings-Zeitraumes (mit all seinen Uptrends, Downtrends und Lateralphasen) profitabel blieben. Diese Einstellung fungiert dann quasi als Grund- oder Master-Einstellung.

Das impliziert aber, dass eine solche Grundeinstellung mit der die Systeme in allen zu erwartenden Trendrichtungen ganz gut laufen, nicht unbedingt auch die am besten geeignete Einstellung für das Trading des Systems am aktuellen Trend ist.

Soll heißen: Wenn man die Systeme in kürzeren Zeitintervallen an den aktuellen Trend anpasst (wartet), kann man dadurch dann deutlich bessere Ergebnisse (bei geringeren Drawdowns) erzielen, als wenn man die Grundeinstellung gar nicht ändert.

Im Gegensatz zu den an zu kurzen Historien entwickelten Systemen ist es dann auch so, dass die Optimierungsergebnisse an einem Trend der aktuellen Trendrichtung auch repräsentativ für das Systemverhalten an früheren Trends der gleichen Trendrichtung sind.
Dieses Verhalten ermöglicht eine Optimierung an den aktuellsten Daten des derzeitigen Trends (=letzte zur Verfügung stehende Kursdaten ohne nachgelagerten Kontrollzeitraum). Kontrollzeitraum kann dann z.B. ein früherer Trend in gleicher Trendrichtung sein, welcher folglich zeitlich vor dem Optimierungszeitraum liegt.

Mein Hauptkritikpunkt an Systemen, die auf Basis kurzer Historien entwickelt wurden ist , dass deren Backtesting-Ergebnisse nicht relevant für das zu erwartende Systemverhalten in der Zukunft sind.
Wäre das anders, müssten auch solche Systeme länger nachlaufen.

In der Quintessenz bin ich also dazu übergegangen, meine Systeme ausschließlich an aus meiner Sicht ausreichend langen historischen Daten zu entwickeln.
Solche Systeme können dann an das aktuelle Marktverhalten noch besser angepasst werden, indem sie auf kürzere Zeiträume optimiert werden. Sie stürzen aber eben auch nicht nach kurzer Zeit ab, wenn sie gar nicht optimiert werden.

Auch wenn auf kürzere Zeiträume optimiert wird, sollten die Optimierungszeiträume nicht zu kurz sein, will man aussagekräftige Ergebnisse erhalten. Der Optimierungszeitraum soll außerdem auch die aktuelle Marktsituation (speziell in Bezug auf den Trend) repräsentieren.
Bewährt haben sich bei mir in der Vergangenheit Optimierungszeiträume von bis zu 1 Kalenderjahr (bei 60-Minuten Candle-Systemen).

Ich würde also klar zwischen den Anforderungen für die Entwicklung robuster HS und den Anforderungen für die laufende Optimierung (= Systemwartung für profitoptimiertes Trading ) unterscheiden wollen.
Während robuste Systeme aus meiner Sicht nur an langen Historien mit unterschiedlichem Marktverhalten zu entwickeln sind, reichen für die laufenden Systemanpassungen solcher robusten Systeme später auch kürzere Historien aus.
Weil sich die Aussage von Tom oben nur auf die laufende Optimierung bezog, vertreten wir in diesem Punkt die gleiche Meinung.
1 Jahr für laufende Optimierungen liegt im 60-Minuten Bereich sogar noch leicht unter 5000 Perioden….

Ein System mit nicht aussagekräftigen Backtesting-Ergebnissen, würde ich persönlich nicht mehr traden wollen – weder auf den laufenden Trend angepasst – erst recht nicht unoptimiert.

Das macht man glaube ich sowieso nur so lange, wie man den Vergleich zum robusten System nicht kennt.

Soweit meine Sicht der Dinge .... =)

Hallo Bernd2,

schön, dass Du mein Posting (..und die Tutorien... ) hilfreich findest.

Ich muss sagen, dass ich wirklich gern etwas schreibe, wenn ich -wie in diesem Thread- den Eindruck habe, dass es andere User interessiert.
Leider ist es manchmal gar nicht so leicht herauszufinden, was eigentlich für andere Anwender interessant ist und was nicht.
Da ist es wirklich schön, wenn Feedback kommt. Dank Dir dafür. =)

Zu den "Mißverständnissen"

1.) Ist klar - habe ich auch so verstanden.

zu 2.)

Tom schreibt ja immer nur "Optimierung".
Ich habe das einfach mal so interpretiert, dass er damit nur die Optimierungen des bereits fix und fertigen Systems im Rahmen der laufenden Systemwartungen meint.
Nur wenn man es so sieht, liegen Tom und ich in Bezug auf die laufenden Optimierungen eines fertigen robusten Systems auf einer Wellenlänge.

Würde Tom aber mit seinem Terminus "Optimierung" auch die während der gesamten Entwicklungsphase des Systems erforderlichen Optimierungen meinen, wären unsere Ansichten zu den Optimierungszeiträumen während des Entwicklungszeitraumes eines robusten HS tatsächlich konträr.


Ich habe klar gemeint:
a) Optimierungen im Rahmen der Systementwicklung bis zur Fertigstellung des robusten Systems : immer an langen Historien
b) laufende Optimierungen des fertigen robusten Systems nach komplett abgeschlossener Systementwicklung: auch an kürzeren Historien


Zumindest in Punkt b) sind Tom und ich einer Meinung. Das wollte ich eigentlich nur herausstellen.

War aber vielleicht wirklich etwas mißverständlich geschrieben....
Gut, dass Du nochmal nachgefragt hast.

@ Tom
Wenn wir uns beide auf die 5000 Perioden beziehen, ist es wirklich egal, dass wir unterschiedliche Komprimierungen verwenden.
Ich meinte also, an 5000 Perioden würde ich ein fertig entwickeltes System optimieren.
Ich würde aber nicht ein Handelssystem nur auf Basis von 5000 Perioden entwickeln.
Das kriegt man dann nach meinen Erfahrungen selbst dann nicht robust genug, wenn man wirklich kaum Optimierungsvariablen verwendet.....

Ich kann aber hier nur für den Bereich ab 30 Minuten aufwärts sprechen.
In kürzeren Komprimierungen entwickle ich ja momentan wegen der leidigen Datenfeed-Problematik nicht....

Hallo Anke

>>Ich kann aber hier nur für den Bereich ab 30 Minuten aufwärts sprechen.
In kürzeren Komprimierungen entwickle ich ja momentan wegen der leidigen Datenfeed-Problematik nicht.... <<<

Aber auch hier tun sich mit Hilfe von M+ ganz neue Möglichkeiten auf-trotz unzureichender Daten..

Zitat

Aber auch hier tun sich mit Hilfe von M+ ganz neue Möglichkeiten auf-trotz unzureichender Daten.. Augenzwinkern

Hallo Udo,

Ich weiß, ich weiß.
Ich habe doch M+ längst und finde es wirklich sehr gelungen. =)

Ich werde bei nächster Gelegenheit austesten, ob sich nicht einige der Filter-Indikatoren in meinen Candle-Systemen besser durch dynamische Histogramme ersetzen lassen.....


Aber:

Welche Möglichkeiten würden sich uns erst mit M+ und zureichenden Daten auftun. ...

Zitat

von den Stopps ganz zu schweigen.

Hallo Bernd2,

.... nach meinen Erfahrungen bergen Optimierungsvariablen in den Systemstops weniger das Risiko der Überoptimierung....

Ich achte primär darauf, in den Handelsregeln eine bestimmte Anzahl von Optimierungsvariablen nicht zu überschreiten.

Die Stops haben bei mir immer alle Optimierungsvariablen. Das ist schon deshalb nötig, weil meine Systeme ja immer an unterschiedliche MM/RM-Profile anpassbar sein müssen.

Bei den Stops ist es außerdem auch so, dass nicht immer alle Stops gleichzeitig aktiviert sind.
Bei deaktivierten Inaktivitäts-Stops sind z.B. schon mal gleich 4 Optimierungsvariablen weniger systemrelevant.
Aber selbst wenn alle Stops aktiviert sind, gehen die Optimierungsvariablen dort kaum zu Lasten der Robustheit.

Hallo Anke,

der Hinweis war werbefrei..)

>>Welche Möglichkeiten würden sich uns erst mit M+ und zureichenden Daten auftun. ...

Es kommt darauf welchen System-Typ Du entwickelst. Nicht immer sind 100%ige Ticks und Volumen notwendig denn der Markt hat einen sehr grossen "Fussabdruck"! Auf den ein oder anderen Tick kommt es bei gewissen strategien nicht an (ich meine IB-Daten)! Anders sieht es aus, wenn Du das Orderbuch scalpen möchtest. Diese Systeme benötigen 99.9% genaue,schnelle Ticks und hohe Datenzuverlässigkeit sowie Datenstabilität-aber kaum historische Daten....

Zitat

Nicht immer sind 100%ige Ticks und Volumen notwendig denn der Markt hat einen sehr grossen "Fussabdruck"!

Hallo Udo,

Ja natürlich.

Der IB-Fußabdruck ist kleiner und vom linken Fuß.
Der Tai-Pan Fußabdruck ist größer und vom rechten Fuß.

Jetzt muss der neue Schuh nur noch beiden gleichzeitig passen....

Aber wir werden schon eine Lösung finden .... Holländer Klompen oder so....-

Hallo Anke,

man darf nicht zwei paar verschiedenen Schuhe anziehen-das ist Plicht..)

@all
Jetzt will ich eueren sehr interessanten Thread nicht weiter stören und wünsche euch weiterhin viel Erfolg beim Systeme erstellen!