Handelssysteme: Adaptive Lookbackperiode im Handelssystem

@ select [#1]

Du hast die Lösung im Prinzip ja schon formuliert:

Wenn Dein "dynamisches" Adaptionsmodell auf der von Dir berechneten Volatilität der Preisänderungen und ihrer reziproken Wirkung auf Deine Loookbackperiode basiert, kannst Du dies ja stark vereinfacht so formulieren:

z.B.
Lookback N = 10 bei hoher Vola
Lookback N = 25 bei mittlerer Vola
Lookback N = 50 bei geringer Vola

(Anm. die Zahlen sind völlig willkürlich gewählt)

Die technische Umsetzbarkeit hängt sehr von der gewählten Entwicklungsumgebung ab. Mit einer professionellen Programmiersprache ist so etwas simpel "dynamisch" im Code zu implementieren. Mit manchen der speziellen HS-Entwicklungs-Scriptsprachen wirst Du allerdings mit der Implementierung Schwierigkeiten haben, weil Du dort i.d.R. weniger Kontrolle über den Ablauf des Systemtests selbst hast bzw. die Möglichkeiten zur Verwendung von Variablen vergleichsweise eingeschränkt sind...

ciao,
zentrader

@ zentrader [#2]

Lookback = ABS(Y*Vola) ?

In Perry Kaufmans "New Trading systems and Methods" sind im Kapitel 17 "Adaptive Techniques" einige Anregungen nebst Easy-Language Codes enthalten.

Was meinst Du mit, an der Zeitachse oder am Preis orientieren, um eine variable Periodenlänge zu erhalten. Wie sieht eine an der Zeitachse orientierte Berechnung der Periodenlänge exemplarisch aus?

@ select [#1]

Obwohl logische Argumentationen gefunden und angebracht wurden muss man sich fragen, ob es möglich ist, hier meine ich die technische Umsetzung, solch einen Prozess zu programmieren.
Technisch möglich ist grundsätzlich alles.

Je mehr flexible Variablen, desto mehr Kombinationsmöglichkeiten. Je mehr Kombinationsmöglichkeiten vorhanden sind, desto geringer wird die Aussagekraft der Ergebnisse.
Durch die Einführung eines Selbst-Optimierungs-Mechanismus werden neue Parameter eingeführt.
Für jede Parameterausprägung müssen genügend Datenpunkte (Trades) vorhanden sein, um annähernd valide Aussagen machen zu können. Andernfalls läuft man direkt in die Curve Fitting-Falle.

@select

mach doch die Lookback-Periode an Hand von Swings (z.B. 2, 4, 8) fest, je nach dem wie hier die Frequenz ist hast du dann mal mehr, mal weniger Bars um z.B. den ATR zu berechnen. Dieser kann dann wiederum in Ziel und SL einfließen.

Mit einer guten SW wie z.B. Amibroker ist eine Umsetzung überhaupt kein Problem.

MfG Henning

@ zentrader [#2]

Diesen Weg will ich ja umgehen, zumindest gedanklich angedacht. Ich überlege, ob es andere Alternativen gibt.

@ wuelle [#4]

"Was meinst Du mit, an der Zeitachse oder am Preis orientieren,"

Wenn ich an der Periodenlänge Adaptionen durchführen möchte, dachte, fragte ich mich, ob man losgelöst der Zeitachse einen Weg finden kann. Also nicht Tage zurückrechnen, sondern sich ausschließlich auf den Preis konzentrieren. Nur ist der Weg einem scheinbar verschlossen, wenn man den Preis von z.B. einem Dailybar ins Verhältnis setzen möchte. Denn die Preisbildung von einem Tag endet eben nach einem Handelstag.

Somit gibt es eigentlich nur zwei Möglichkeiten: Entweder ich konstruiere aus zurückliegenden Daten eine Auswertung oder nutze ausschließlich den letzten Handelstag, um Prognosen für die Zukunft zu ermitteln. Ich werde zu diesem Thema nochmals bei John C. Hull nachlesen, wo die Gedanken um die Wiener-Prozesse abgehandelt wurden. Sinnvoller weise wäre das eine Alternative zur Vergangenheitsbetrachtung, da die Markov-Eigenschaft besagt, dass die Wahrscheinlichkeitsverteilung der Kurses zu irgendeinem zukünftigen Zeitpunkt eben nicht von dem Kursverkauf in der Vergangenheit abhängig ist.

@ tradingscape [#5]

"Durch die Einführung eines Selbst-Optimierungs-Mechanismus werden neue Parameter eingeführt."

Darum geht es grundsätzlich.

@ Henning [#6]

"mach doch die Lookback-Periode an Hand von Swings (z.B. 2, 4, 8) fest"

Klar, aber die SH und SL bedürfen zum entstehen einer Lookbackperiode. Dadurch kommen Ergebnisse auch immer zu spät:-)

@ select [#7]

Sorry, ich war gedanklich noch nicht ganz bei Dir.
Ich habe mich mit Selbstoptimierung eine ganze Weile nicht mehr beschäftigt. Ich würde es vielleicht so machen: ich würde nicht eine sondern vielleicht 200 Selbstoptimierungsläufe machen (jeder Lauf für den jeweiligen Bar davor) und für die 200 ermittelten Werte je Parameter jeweils einen Trend und/oder gleitenden Durchschnitt ermitteln.

Angenommen die Vola nimmt zu und dein Dual-MA-System (als Beispiel) performt neuerdings mit kürzeren Perioden besser, dann müsste sich das theoretisch am Trend der beiden Parameter (Periode) erkennen lassen.

Somit schleift man zwar den neuen Parameter (200) ein, sollte ihn aber - nach meinem Verständnis - auf diese Weise "neutralisieren" im Sinne von CF-Gefahr.

Was spricht dagegen mehrere Equitykurven verschiedener Parameterkombis parallel zu betrachten und zu denen zu switchen, die anfangen besser zu performen als die aktuelle?

@ select [#1]

zunächst Definition:

Lookback bedeutet: für die Berechnung greife ich auf zurückliegende Kursdaten (Bars) einer Zeitreihe zurück und verwende nicht nur das aktuellste verfügbare Kursdatum (die most recent bar).

Folgende Regel dient als Grundlage: Wenn sich die Volatilität im Markt vergrößert, wird die Lookbackperiode verkürzt, nimmt die Volatilität ab, wird die Lookbackperiode verlängert.

Warum so? Warum nicht bspw. umgekehrt? Was ist die Überlegung und Motivation hinter der Regel? Ich würde da gerne folgen können.

Welche Ideen gibt es, um eine adaptive Lookbackperiode zu programmieren?

das hängt ganz davon ab, für welche Berechnung Du sie überhaupt brauchst.

@ Global_2 [#10]
@ select [#1]

Adaptive(=variable) Lookbackperiode... Selbstoptimierung... rollierende Optimierung:

Vergessen wir mal kurz Grundsatzdiskussionen über Sinn/Unsinn von (Über)Optimierung und verallgemeineren wir das Ziel etwas:

Nehmen wir also an, wir haben einen Handelsansatz mit ein paar variablen Parametern und können/wollen auf Grundlage der JEWEILS letzten 3Monate/Quartale/... ein gutes Ergebnis für 1..2Wochen realisieren.

Um so etwas zu realisieren, muss die Systemsoftware sowohl für "Backtest" also auch den Livehandel immer drei automatisierbare rückgekoppelte Grundfunktionen bieten:

-v TestStart=DatenStart+3Monate/Quartale
--
| v
|(1) regel- und/oder marktabhängige Parametereinstellung (z.B. "adaptive Lookbackperiode" über Vola,...)
|(2) weitere "variable" Systemparameter für die "automatische Optimierung" über Vorgabe des Wertebereichs und der Schrittweite
|(3) Feedbackregeln zur "optimalen" Parameter(bereichs)selektion (min. Drawdown, max. Profit,...)
|_v z.B. +1 Woche/Monat solange kleiner (Live)Datenende

Fast jede aktuelle Software kann die Punkte 1..3 für einen vorgegebenen Testzeitraum (bzw. den gesamten Datenbereich) irgendwie realisieren. Punkt (1) meist per script, Punkt (2)&(3) per Programm(dialog)funktion.

Spannend wird es, wenn es darum geht, "eingebettet" in eine äußere Bereichsfunktion diese Optimierungen jeweils für den aktuell "gültigen" Teilzeitraum durchzuführen und auch hier rückgekoppelt eventuell noch die Optimierung anzupassen.

Aber bitte nicht verwechseln mit "einfachen" inSample/OutSample Test&Optimierungsverfahren!... hier ginge es dann auch hierfür noch um die automatisch fortlaufend rollierende Bereichsoptimierung, also z.B. wochenrollierend{BestOf(Optimierung[3Wochen(InSample)+1Woche(OutSample)])->1Woche Trading mit den gefundenen "BestOf" Parametern)}... (Nanotrader und Investox bieten diese "einfachen" InSample/Outsample Optimierungen)

Eine (frei) käufliche Standardsoftware, welche echte parametriebare rückgekoppelte rollierende Optimierung bietet, ist mir aktuell nicht bekannt. Überoptimierung ist für viele ein rotes Tuch, aber warum nicht mal über den eigenen Schatten springen und die Tatsache nutzen, das sich scheinbar doch irgendwie Märkte für einen bestimmten "kurzen" Zeitraum mit parametrierbaren Regeln abbilden lassen. Was ist eigentlich so schlimm an der Vorstellung, jede Woche sein System zu "optimieren"?!

Adaptive Systeme... klingt einfach besser:) Ich nenne das einfach ständige/fortlaufende rollierende Optimierung
Überoptimierung... von mir aus gerne, wenn man sich der kurzfristigen "Gültigkeit" bewußt ist, warum denn nicht

So, jetzt sollte ich mit dem Schreiben aufhören, denn wer zu solchen Gedanken öffentlich steht wird erfahrungsgemäß ganz schnell mit vielen Argumenten, das nicht sein kann was nicht sein soll zerrissen. In Fachbüchern hat sich meines Wissens auch noch keiner "getraut" sowas mal seriös und nachvollziehbar zu analysieren. Die allgemine "Aversion" gegen (Über)Optimierung begründet sich für mich nur in der Unkenntnis der technischen Möglichkeiten dieses Verfahren übergeordnet nochmals automatisiert "rollierend" einzusetzen...

@ TimeTrade [#11]

oh, das war ja jetzt sogar eine lange, ausführliche Antwort.

Ich hatte in [#10] bewusst naiv gefragt, weil die vorangegangenen Beiträge teilweise etwas wirr waren und dadurch Folgeantworten eher erschwert sind.

Mögliche Begründungen für die in #1 postulierte Regel kann ich mir schon denken, aber es ist eben nachteilig, wenn man da als Leser Vermutungen anstellen muss, weil die Begründung zur Regel fehlte. Eine mögliche Begründung könnte z.B. sein: "Bei höherer Vola kommt ein Moving Average mit großer Periodenlänge nicht schnell genug hinter den Kursbewegungen hinterher, deswegen dann vola-gesteuert eine Verkürzung der Periodenlänge." Aber für andere Zielberechnungen statt für MAs könnte man auch völlig andere Regeln postulieren, daher eben meine Frage nach der Regelbegründung.

Gut war aber auf jeden Fall schon mal die Antwort von Zentrader: "Die technische Umsetzbarkeit hängt sehr von der gewählten Entwicklungsumgebung ab. Mit einer professionellen Programmiersprache ist so etwas simpel ... im Code zu implementieren. Mit manchen der speziellen HS-Entwicklungs-Scriptsprachen wirst Du allerdings mit der Implementierung Schwierigkeiten haben, ...."

Interessant gefunden hätte ich, wenn Select konkreter geschrieben hätte, was er dann eigentlich genau macht. Vielleicht an einem Beispiel, das auch zeigt, dass der Ansatz in der Praxis überhaupt einen Vorteil gegenüber einem nicht-adaptiven Verfahren liefert.

@ select [#7]

da die Markov-Eigenschaft besagt, dass die Wahrscheinlichkeitsverteilung der Kurses zu irgendeinem zukünftigen Zeitpunkt eben nicht von dem Kursverkauf in der Vergangenheit abhängig ist.

das basiert dann aber auf der Random-Walk-Hypothese. Und haste die als Trader?

@ gautama2 [#9]

"Was spricht dagegen mehrere Equitykurven verschiedener Parameterkombis parallel zu betrachten und zu denen zu switchen, die anfangen besser zu performen als die aktuelle?"

->

ich denke, das hängt ganz davon ab, ob man die Frage "Zufallszeitreihe" mit JA oder NEIN beantworten kann/möchte/will.

Auch in Zufallszeitreihen gibt es phasenweise über längere Zeit stabile "innere" Tendenzen und Muster. Das Problem dabei ist, der Zeitpunkt des Erscheinens und wie lange sie andauern ist wiederum auch zufällig. So dass Dir dieses Wissen bei Zufallszeitreihen nichts nützt.

In Charts von Zufallszeitreihen würde jeder halbwegs geübte Trader Trendlinien finden und Dreiecke einzeichnen können und felsenfest überzeugt sein, den Zufall überwinden zu können ...

Die Frage ob Zufall oder nicht, würde ich persönlich mit Nein beantworten, einfach auf Grund der Tatsache, dass ein gekaufte Aktie auch wieder verkauft werden muss.
Dieser Verkauf also irgendwie "vorbestimmt" ist, und meistens die Unendlichkeit nie erreicht. Bei Daytrading erfolgt die Auflösung der Position sogar "vorraussichtlich" (und nicht zufällig) innerhalb eines Tages ..

@ TimeTrade [#11]
"Eine (frei) käufliche Standardsoftware, welche echte parametriebare rückgekoppelte rollierende Optimierung bietet, ist mir aktuell nicht bekannt."

Mit TradingBlox geht das, wenn auch zugegeben nicht out-of-the-box. Man müßte Daten auf Files schreiben und wieder einlesen. Mit allen anderen Umgebungen, die rollierende Tests ermöglichen und mit Files kommunizieren können, sollte es ebenso gehen.

@ gautama2 [#9]
"Was spricht dagegen mehrere Equitykurven verschiedener Parameterkombis parallel zu betrachten und zu denen zu switchen, die anfangen besser zu performen als die aktuelle?"

Das ist immer die gleiche Fragestellung: entweder glaubt man, aufgrund der Preisbewegungen der jüngeren Vergangenheit Aussagen über die nähere Zukunft machen zu können, oder nicht. Wenn man glaubt, daß das nicht möglich ist, rühren die Unterschiede zwischen Deinen verschiedenen Parameter-Kombis von etwas her, was keine Vorhersagekraft hat, und damit ist der Wechsel sinnlos, und im Normalfall sogar schädlich.

Schädlich ganz ähnlich wie die inzwischen verbreitete Erkenntnis, warum Privatanleger, die in Fonds investieren, als Gruppe nicht mal die Performance einzelner Fonds schaffen. Die Fonds haben schwankende Wert-Verläufe, und viele Leute kaufen nach Anstiegen und Verkaufen nach Verlusten, was genau verkehrt herum ist und zur geringeren Performance führt.

Ähnlich bestünde bei Deiner Methode die (in meinen Augen reale und große) Gefahr, daß Du in Summe eine Performance erreichst, die schlechter ist als die von jedem einzelnen Deiner Kombis. Weil Du nämlich gerade die Anstiege eines Systems verpaßt, und ihm erst dann folgst, wenn das Systeme kürzlich gut performte. Nun könnte die beiden anderen Systeme einen Lauf haben, den Du ebenfalls nicht mitnimmst.

Was Du vorschlägst ist eine besondere Form von "Traden der Equity-Kurve". Ob die Equity-Kurve eines System Voraussagekraft hat, darüber besteht meines Wissens ziemlich Einstimmigkeit. Sie hat es dann, wenn es Information in den Daten gibt, die bei des Systemerstellung nicht genutzt wurde. Wenn dem so ist, ist es jedoch besser, die Info zu identifizieren und direkt im System zu verwenden, als indirekt über das "Traden der Equity-Kurve".

@ Asamat [#14]
Mein Vorschlag bezog sich auf die #8 , das regelmäßige Optimieren von Parametern und dann die besten zu traden, was ja auch timetrade später für nicht abwegig hielt. Anstatt immer neu zu optimieren und nur kleine Momentaufnahmen zu betrachten, gibt die Betrachtung von Equityurven der verschiedenen Parametervarianten ein besseres Bild darüber, in welcher Verfassung sich gerade die kürzlich besser laufenden Varianten befinden.

"Ähnlich bestünde bei Deiner Methode die (in meinen Augen reale und große) Gefahr, daß Du in Summe eine Performance erreichst, die schlechter ist als die von jedem einzelnen Deiner Kombis."
Aber warum soll ausgerechnet eine von mir gewählte "Standard"-Variante, von Parametern, die Herr Dow mal durch "von Hand Optimierung" vor hundert Jahren für gut befand und die ich dann einfach blind beibehalte, auf jeden Fall besser sein als meine Switchhistorie? Die Gefahr dass ich schlechter abschneide besteht natürlich, aber ist sie größer als die Chance durch konstante Parameter besser zu sein?

@ gautama2 [#15]

Im Wesentliche wollte ich nur sagen: die Performance mit Switchen kann sehr viel schlechter sein, nicht nur besser, wie man auf den ersten Blick vielleicht hoffen könnte. Was davon zutrifft, weiß ich naütlich nicht, und hängt klarerweise von den Handelsansätzen und den jeweiligen Zeitskalen ab. Also welche Trade-Dauern handeln die Systeme typischerweise, und welche Switch-Frequenz ist angestrebt.

Ob die Performance durch Switchen zwischen verschiedenen Systemen besser wird, dazu kann man in meinen Augen nur
- entweder raten, oder
- es durch Backtests herausfinden. Mit allem Wissen, daß Backtests nur eine beschränkte Aussage über die Zukunft erlauben. Aber eben besser als raten.