Sinn (und Unsinn) von Backtests?

[MarsDaGabor]

vor 5 Stunden schrieb Maaz:

Ich habe meine ersten Bots ebenfalls selber programmiert, basierend auf technischen Indikatoren. Genau dafür wurde Freqtrade gebaut und dort sind schon viele Fallstricke beseitigt, die dir vermutlich noch über den Weg laufen werden.

Als Bonus bekommst Du Backtests, Auswertemöglichkeiten und Schnittstellen zu Telegram, Discord und ein Webfrontend.

Es gibt auch einen - aktuell sehr aktiven - Machine Learning Zweig von Freqtrade, falls dich das interessiert. Nennt sich FreqAI.

Der Discord-Channel ist sehr aktiv. Dort werden auch regelmäßig Strategien diskutiert und es gibt Leute, die Strategiesammlungen im Dry-Run laufen lassen und die Ergebnisse bereitstellen. Falls du dir dort was rauspicken möchtest. https://discord.gg/p7nuUNVfP7

Aber selber programmieren hat auch Vorteile. Dadurch lernt man ja einiges.

 

Genau diese Gedanken wäge ich aktuell gegeneinander ab. Ich merke auch, dass das Programmieren-Lernen und alles selbst machen sehr viel Wissen vermitteln, auch wenn es eben nur langsam voran geht. Auf der anderen Seite möchte ich auch relativ schnell zum eigentlich Zweck, dem Bot-Trading vorstoßen und möchte auch gerne vermeiden selbst Bugs oder Sicherheitslöcher bei eigenen Scripten zu bauen. Dahingehend ist ein Framework wie Freqtrade schon sehr hilfreich bzw. eine Abkürzung, auch wenn ich dann erstmal zusätzlich noch Docker und Co verstehen muss. Und das von dir und Chantal  angesprochene ML bzw. Reinforcement Learning klingt vielversprechend. Manchmal möchte ich wie Neo aus Matrix eine Disc einschieben und all das schnell zu lernen. 😅

[PeWi]

Hier noch ein Artikel zum Thema Backtests - bezieht sich zwar auf das Tradingssystem "Zorro" - man kann IMHO trotzdem einiges mitnehmen:

https://financial-hacker.com/why-90-of-backtests-fail/

[PeWi]

Hab die Tage einen interessanten Artikel über Overfitting gelesen.

Zum einen ist es frustrierend, dass er schon bei einer mickrigen Zahl an Parametern - die ich regelmäßig und grundsätzlich deutlich überschreite - von Overfitting spricht.

Andererseits sagt er - durchaus verblüffend - dass etwas Overfitting gar kein so großes Problem ist, wenn (und das ist der Knackpunkt) man erkennt, wann sich die Marktverhältnisse ändern und man demzufolge neu optimieren muss.
Und dass man sich die Verluste beim Übergang auf neue Marktverhältnisse durchaus leisten kann, wenn man vorher dank Overfitting mehr gewonnen hat.

 

https://www.priceactionlab.com/Blog/2023/01/trend-following-parameter-and-optimization-space/

[PeWi]

Ein Schwachpunkt meiner bisherigen Backtests ist, dass sie nach einer "statisch besten Kombination" suchen.  

Statisch heißt, dass die Parameter der einzelnen Backtestsätze über alle Testzeiträume gleich bleiben und keine Möglichkeit haben, sich bei ändernden Marktverhältnisse irgendwie ebenfalls zu ändern. Der jeweilige Parametersatz muss also mit Trendmärkten und mit Seitwärtsmärkten, mit viel oder wenig Volatilität und mit ruppigen oder sanften Verhältnissen zurecht kommen.

Bei einer meiner Strategien habe ich testweise mal versucht, adaptive Elemente einzubauen. Weil ich aber vorab nicht weiß, wie stark ich was adaptieren muss, steuere ich das über zusätzliche Parameter, deren sinnvolle Werte ich ebenfalls über meine Backtestläufe ermittle.

Das hat zwei Nachteile: Zum einen wächst die Gesamtzahl meiner Strategieparameter dadurch noch mehr, und zum andern wird die jeweilige Adaption dann auch wieder statisch für immer und ewig festgelegt.

Man bräuchte folglich eine Möglichkeit, die Parameter regelmäßig verändern zu können - und das idealerweise auch auf eine systematische und testbare Art.

Das versucht die Walk-Forward-Optimization, die zudem eleganterweise für das Testergebnis nur Out-of-Sample-Ergebnisse verwendet.

Das Grundprinzip: Man schneidet den Testzeitraum in mehrere, gleichgroße Teile und optimiert und testet sich stückweise sukzessive durch den Gesamtzeitraum. Sprich, man optimiert jeweils auf dem Teil-Zeitraum <n-1> und testet die optimierten Parameter dann auf dem nachfolgenden Teil-Zeitraum <n>. Und das wiederholt man solange, bis man durch den Gesamtzeitraum durch ist.

Das Gesamtergebnis wird dann aus den Out-of-Sample-Teilstücken zusammengesetzt.

Dazu ein Bild (siehe unten) aus dem Artikel https://algotrading101.com/learn/walk-forward-optimization/

DIe Schwierigkeit für mich - abgesehen davon, dass ich meinen ganzen Backtest wieder erweitern/umarbeiten darf:

Um das ganze automatisch ablaufen zu lassen, muss der Backtest bein jedem Walk-Forward-Schritt selber eine gute Lösung aus den Optimierungen des Zeitraums <n-1> herausfischen können. Das ist nicht trivial, weil man ja nicht einfach die mit den besten Werten herausfischen kann, sondern sicherstellen muss, dass man eine robuste Lösung und keine nur punktuell gute aussucht.

Dazu habe ich noch keine richtig gute Idee - nur die rechenaufwendige Methode, jeden geeignet erscheinenden Parametersatz zu verrauschen und das neue Ensemble nochmal durchrechnen zu lassen. Liegt der Großteil der Ensemble-Sätze vom Ergebnis ähnlich und der Originalsatz im mittleren Drittel aller Ensemble-Ergebnisse, dann sollte er robust sein.

Oder kennt jemand einen praktikablen Algorithmus, in einem n-dimensionalen Raum (unsaubere) Plateaus zu identifizieren?

 

Ergänzung: Die Grundidee der Walk-Forward-Optimization ist ganz pfiffig, funktioniert in voller Pracht aber dann am besten, wenn sich die Marktverhältnisse eher allmählich und nicht häufig bzw abrupt ändern.  Das ist im Kryptobereich aber nicht unbedingt gegeben - aber besser als dauerhaft die gleichen Parameter wird es allemal sein.

 

Bearbeitet 6. Februar 2023 von PeWi
Formatierung + Ergänzung

[Arther]

1 hour ago, PeWi said:

Oder kennt jemand einen praktikablen Algorithmus, in einem n-dimensionalen Raum (unsaubere) Plateaus zu identifizieren?

Bin mir nicht sicher, ob dir das hilft, aber Simulated Annealing ist mir beim Lesen als Stichwort eingefallen. Davon abgesehen: Gibt es denn (teilweise) einen (stetigen/differenzierbaren) Zusammenhang zwischen den Parametern und dem Zielwert? Dann könntest du Gradientenverfahren anwenden. Ich vermute aber, dass es nicht so simpel ist.

[PeWi]

2 hours ago, Arther said:

Davon abgesehen: Gibt es denn (teilweise) einen (stetigen/differenzierbaren) Zusammenhang zwischen den Parametern und dem Zielwert?

Da bin ich völlig überfragt.

2 hours ago, Arther said:

Bin mir nicht sicher, ob dir das hilft, aber Simulated Annealing ist mir beim Lesen als Stichwort eingefallen.

Muss ich mir mal anschauen.

[Chantal Krüger II]

On 2/6/2023 at 6:23 PM, PeWi said:

Ein Schwachpunkt meiner bisherigen Backtests ist, dass sie nach einer "statisch besten Kombination" suchen.  

Statisch heißt, dass die Parameter der einzelnen Backtestsätze über alle Testzeiträume gleich bleiben und keine Möglichkeit haben, sich bei ändernden Marktverhältnisse irgendwie ebenfalls zu ändern. Der jeweilige Parametersatz muss also mit Trendmärkten und mit Seitwärtsmärkten, mit viel oder wenig Volatilität und mit ruppigen oder sanften Verhältnissen zurecht kommen.

Bei einer meiner Strategien habe ich testweise mal versucht, adaptive Elemente einzubauen. Weil ich aber vorab nicht weiß, wie stark ich was adaptieren muss, steuere ich das über zusätzliche Parameter, deren sinnvolle Werte ich ebenfalls über meine Backtestläufe ermittle.

Das hat zwei Nachteile: Zum einen wächst die Gesamtzahl meiner Strategieparameter dadurch noch mehr, und zum andern wird die jeweilige Adaption dann auch wieder statisch für immer und ewig festgelegt.

Man bräuchte folglich eine Möglichkeit, die Parameter regelmäßig verändern zu können - und das idealerweise auch auf eine systematische und testbare Art.

Das versucht die Walk-Forward-Optimization, die zudem eleganterweise für das Testergebnis nur Out-of-Sample-Ergebnisse verwendet.

Das Grundprinzip: Man schneidet den Testzeitraum in mehrere, gleichgroße Teile und optimiert und testet sich stückweise sukzessive durch den Gesamtzeitraum. Sprich, man optimiert jeweils auf dem Teil-Zeitraum <n-1> und testet die optimierten Parameter dann auf dem nachfolgenden Teil-Zeitraum <n>. Und das wiederholt man solange, bis man durch den Gesamtzeitraum durch ist.

Das Gesamtergebnis wird dann aus den Out-of-Sample-Teilstücken zusammengesetzt.

Dazu ein Bild (siehe unten) aus dem Artikel https://algotrading101.com/learn/walk-forward-optimization/

DIe Schwierigkeit für mich - abgesehen davon, dass ich meinen ganzen Backtest wieder erweitern/umarbeiten darf:

Um das ganze automatisch ablaufen zu lassen, muss der Backtest bein jedem Walk-Forward-Schritt selber eine gute Lösung aus den Optimierungen des Zeitraums <n-1> herausfischen können. Das ist nicht trivial, weil man ja nicht einfach die mit den besten Werten herausfischen kann, sondern sicherstellen muss, dass man eine robuste Lösung und keine nur punktuell gute aussucht.

Dazu habe ich noch keine richtig gute Idee - nur die rechenaufwendige Methode, jeden geeignet erscheinenden Parametersatz zu verrauschen und das neue Ensemble nochmal durchrechnen zu lassen. Liegt der Großteil der Ensemble-Sätze vom Ergebnis ähnlich und der Originalsatz im mittleren Drittel aller Ensemble-Ergebnisse, dann sollte er robust sein.

Oder kennt jemand einen praktikablen Algorithmus, in einem n-dimensionalen Raum (unsaubere) Plateaus zu identifizieren?

 

Ergänzung: Die Grundidee der Walk-Forward-Optimization ist ganz pfiffig, funktioniert in voller Pracht aber dann am besten, wenn sich die Marktverhältnisse eher allmählich und nicht häufig bzw abrupt ändern.  Das ist im Kryptobereich aber nicht unbedingt gegeben - aber besser als dauerhaft die gleichen Parameter wird es allemal sein.

 

 

Du findest die Antwort bei John Ehlers. Genau darauf beruht seine gesamtes Werk, die aus der Signaltheorie kommt. 

Darin sieht Ehlers eine Preiskurve als Sinuskurve an, dessen Frequenz sich dynamisch ändert. Wenn man also diese Zyklen richtig erfasst, hat man genau das, was Du suchst. Da kannst Du Dir dann diese Art von Walk Forward sparen. Eine seiner letzten Arbeiten waren dann in einem n-dimensionalem Raum, aber das habe ich mir nicht angeschaut.

 

 

 

Bearbeitet 7. Februar 2023 von Chantal Krüger II

[Chantal Krüger II]

22 hours ago, Arther said:

Bin mir nicht sicher, ob dir das hilft, aber Simulated Annealing ist mir beim Lesen als Stichwort eingefallen. Davon abgesehen: Gibt es denn (teilweise) einen (stetigen/differenzierbaren) Zusammenhang zwischen den Parametern und dem Zielwert? Dann könntest du Gradientenverfahren anwenden. Ich vermute aber, dass es nicht so simpel ist.

Nein, weil Du damit nicht die Zukunft erfassen kannst.

[PeWi]

3 hours ago, Chantal Krüger II said:

Darin sieht Ehlers eine Preiskurve als Sinuskurve an, dessen Frequenz sich dynamisch ändert. Wenn man also diese Zyklen richtig erfasst, hat man genau das, was Du suchst. Da kannst Du Dir dann diese Art von Walk Forward sparen.

Das scheint nicht schlecht zu sein:

"The previous article dealt with indicators based on correlation with a trend line. This time we’ll look into another correlation-based indicator by John Ehlers. The new Correlation Cycle indicator (CCY) measures the price curve correlation with a sine wave. This works surprisingly well – not for generating trade signals, but for a different purpose."

https://financial-hacker.com/petra-on-programming-the-correlation-cycle-indicator/

[Chantal Krüger II]

18 hours ago, PeWi said:

Das scheint nicht schlecht zu sein:

"The previous article dealt with indicators based on correlation with a trend line. This time we’ll look into another correlation-based indicator by John Ehlers. The new Correlation Cycle indicator (CCY) measures the price curve correlation with a sine wave. This works surprisingly well – not for generating trade signals, but for a different purpose."

https://financial-hacker.com/petra-on-programming-the-correlation-cycle-indicator/

Genau, den im speziellen habe ich mir noch nicht genau angesehen. Aber es baisert immer auf der Annahme von Cyclen. Kannst Du Dir wunderbar mit einer FFT ansehen.

Berichte doch einfach, wenn Du was hast, ich sehe darin auch viel Potential. Jedoch haben Freunde von mir grossen Erfolg mit der sogenannten Spieletheorie, da will ich jetzt einsteigen.

Bearbeitet 8. Februar 2023 von Chantal Krüger II

[PeWi]

Hier mal eine konkrete Ausgestaltung einer Walk Forward-Optimierung am Beispiel des Tradingsystems "Zorro" (Forex und Stocks/ETFs über Broker, mit zusätzlichen Plugins auch Binance etc).

Man schreibt in einer C-ähnlichen Sprache nur die Tradinglogik, fast alles Drumherum ist bereits in Zorro eingebaut (ähnlich anderen Systemen wie MetaTrader etc).

Zuerst gibt man an, in wie viele Teile (Zahl der WFO-Zyklen) der Backtestzeitraum geteilt werden soll. Zusätzlich kann man einen Splitwerte für die Daten angeben, also das Verhältnis zwischen In Sample-Candles und Out of Sample-Candles wählen. Ein typischer Wert ist z.B. 75, d.h. man verwendet drei mal so viele Werte zum Bestimmen der jeweils optimalen Parameter als zum Out of Sample-Test. (Danach schiebt man das Fenster jeweils um die Out of Sample-Länge nach hinten und wiederholt das Prozedere.)

Jeder Parameter, der optimiert werden soll, wird mit vier Werten spezifiert:

- Defaultwert (sollte sinnvoll gewählt werden)
- Startwert des Wertebereichs
- Endwert des Wertebereichs
- Schrittweite für den Weg durch den Wertebereich

Im Gegensatz zu meiner Vermutung werden bei der Defaultmethode die Parameter einzeln hintereinander optimiert.

Damit ergeben z.B. vier Parameter mit je 10 Werten keine 10^4=10.000 Kombinationen, sondenr nur 4*10=40 Kombinationen.  Wenn nur ein Parameter auf einmal optimiert wird, ist es auch sehr viel einfacher, die Berge und Täler, Spitzen und Plateaus zu erkennen.
Von den anderen Parametern wird entweder der optimierte Wert verwendet (falls schon ermittelt) oder der Defaultwert (falls noch nicht optimiert).

Das erklärt, warum die Parameterkombination schon brauchbar sein muss, und der jeweilige Defaultwert etwas taugen muss.  Denn der erste Parameter wird optimiert für die Defaultwerte der anderen drei Parameter, der zweite mit dem optimalen ersten Parameter und den Defaultwerten für Patrameter 3 und 4, und so weiter.

Wenn die Defaultwerte nichts taugen, wird auch die Optimierung des ersten Parameters nichts taugen.

Diese Methode des seriellen Optimierens hat deutliche Vorteile, was die Rechenzeit und - normalerweise - die Robustheit des Ergebnisses betrifft. Sie schwächelt, wenn die Parameter voneinander abhängig sind.

Fairnesshalber muss man sagen, dass Zorro außer der seriellen Optimierung auch andere Methoden des Optimierens kennt, z.B. Brute Force aller Parameterkombinationen oder die genetische Optimierung der Parameterwerte.

Diese anderen Methoden erhöhen die Rechenzeit heftig und sind wesentlich anfälliger für Overfitting. Insofern mit Vorsicht zu genießen und eher für Spezielfälle zu verwenden.

Nebenbei: Interessant ist, dass Zorro automatisch für jedes Asset einzeln optimiert. D.h. in unserem Fall, dass jedes Coinpaar seine eigenen, auf sich optimierten Parametersätze bekommt.

Wer sich genauer für die Details interessiert, kann unter folgenden Links nachschauen:

https://zorro-project.com/manual/en/training.htm
https://zorro-project.com/manual/en/opt.htm

 

[PeWi]

Seit zwei Wochen kann mein Backtest auch WFO ("Walk Forward Optimization", siehe ein paar Posts weiter oben). Das beseitigt zwei große Probleme meines bisherigen Designs:
 

a) Bisher lief der Backtest über verschiedene Testzeiträume und Parameterkombinationen und hat eine Ergebnistabelle ausgespuckt, von der ich mir eine Parameterkombination ausgesucht habe. Diese eine Kombination sollte - vom Grundprinzip her - dann mit allen Marktverhältnissen zurecht kommen und idealerweise noch merklich Gewinn abwerfen.
Das ist ein statisches Prinzip, was in einem dynamischen Umfeld wie den Kryptomärkten eigentlich von Haus aus nicht so prickelnd funktionieren kann.

b) Ich habe gleichzeitig auf den Zeiträumen getestet und optimiert. D.h. die Ergebnisse sind In-Sample-Tests, die von der Theorie her sowieso wenig taugen, und damit nur allzuleicht an Overfitting leiden. Ich habe versucht, dass über manche Maßnahmen etwas in den Griff zu bekommen, im Rückblick hat das IMHO aber wenig geholfen.

Durch das Prinzip der WFO bleibt die Parameterkombination dynamisch, da sie in regelmäßigen Abständen neu ermittelt wird. Damit kann - in der Theorie - die Strategie an neue Marktbedingungen adaptieren.

In der Praxis hat das natürlich nur begrenzt hin, weil sich Änderungen im Marktumfeld nicht an die regelmäßigen WFO-Teständerungen halten, sondern nach Lust und Laune "irgendwann" auftreten. Und: Bis sich nach einer Änderung wieder stabile Verhältnisse eingeschwungen haben, dauert es ja auch ein bisschen. Und noch ein letzter Punkt, der gerade beim Kryptos heikel ist: Wenn die Änderungsgeschwindigkeit der Marktverhältnisse höher ist als die "Streifengröße" bei der WFO, dann ist man mit seinen optimierten Parametersätzen meistens zu spät dran.

Ein klarer Vorteil ist, dass die Testergebnisse bei WFO ausschließlich Out-of-Sample sind. Sprich, sie sind nicht mehr overfittet, sondern erschreckend ungeschönt, dementsprechend mau und damit vermutlich realistisch.

Das hilft ungemein, viele Ideen schneller in die Tonne zu treten, weil die Schönung durch Overfitting wegfällt, und man gleich realistische Ergebnisse bekommt.

Was ich bisher nicht eingebaut habe, ist das beim Tradingsystem "Zorro" beschriebene Aussuchen einer robusten Lösung, d.h. einer, deren Parameter aus einem Plateau stammen. So, wie ich die Beschreibung bei "Zorro" verstanden habe, braucht man dazu eine bereits prinzipiell taugliche Parameterkombination, die man dann ein bisschen besser und/oder robuster machen will.

Für diese Art der Suche müsste ich meinen Backtest umfangreich umschreiben, weswegen ich derzeit einen einfacheren Weg gehe: Ich suche mir die jeweilige Parameterkombination pro Optimierungszeitraum über mehrere Kennzahlen aus, d.h Sharpe Ratio, maximaler Drawdown und Endvermögen, die in einem vernünftigen Verhältnis stehen müssen. Da Drawdown und Endvermögen normalerweise Antipoden sind, hoffe ich, dass bei einem vernünftigen Verhältnis aller Kennzahlen auch eine taugliche Kombination heraus kommt.

Bearbeitet 13. September 2023 von PeWi
Formatierung

[Chantal Krüger II]

6 hours ago, PeWi said:

Seit zwei Wochen kann mein Backtest auch WFO ("Walk Forward Optimization", siehe ein paar Posts weiter oben). Das beseitigt zwei große Probleme meines bisherigen Designs:
 

a) Bisher lief der Backtest über verschiedene Testzeiträume und Parameterkombinationen und hat eine Ergebnistabelle ausgespuckt, von der ich mir eine Parameterkombination ausgesucht habe. Diese eine Kombination sollte - vom Grundprinzip her - dann mit allen Marktverhältnissen zurecht kommen und idealerweise noch merklich Gewinn abwerfen.
Das ist ein statisches Prinzip, was in einem dynamischen Umfeld wie den Kryptomärkten eigentlich von Haus aus nicht so prickelnd funktionieren kann.

b) Ich habe gleichzeitig auf den Zeiträumen getestet und optimiert. D.h. die Ergebnisse sind In-Sample-Tests, die von der Theorie her sowieso wenig taugen, und damit nur allzuleicht an Overfitting leiden. Ich habe versucht, dass über manche Maßnahmen etwas in den Griff zu bekommen, im Rückblick hat das IMHO aber wenig geholfen.

Durch das Prinzip der WFO bleibt die Parameterkombination dynamisch, da sie in regelmäßigen Abständen neu ermittelt wird. Damit kann - in der Theorie - die Strategie an neue Marktbedingungen adaptieren.

In der Praxis hat das natürlich nur begrenzt hin, weil sich Änderungen im Marktumfeld nicht an die regelmäßigen WFO-Teständerungen halten, sondern nach Lust und Laune "irgendwann" auftreten. Und: Bis sich nach einer Änderung wieder stabile Verhältnisse eingeschwungen haben, dauert es ja auch ein bisschen. Und noch ein letzter Punkt, der gerade beim Kryptos heikel ist: Wenn die Änderungsgeschwindigkeit der Marktverhältnisse höher ist als die "Streifengröße" bei der WFO, dann ist man mit seinen optimierten Parametersätzen meistens zu spät dran.

Ein klarer Vorteil ist, dass die Testergebnisse bei WFO ausschließlich Out-of-Sample sind. Sprich, sie sind nicht mehr overfittet, sondern erschreckend ungeschönt, dementsprechend mau und damit vermutlich realistisch.

Das hilft ungemein, viele Ideen schneller in die Tonne zu treten, weil die Schönung durch Overfitting wegfällt, und man gleich realistische Ergebnisse bekommt.

Was ich bisher nicht eingebaut habe, ist das beim Tradingsystem "Zorro" beschriebene Aussuchen einer robusten Lösung, d.h. einer, deren Parameter aus einem Plateau stammen. So, wie ich die Beschreibung bei "Zorro" verstanden habe, braucht man dazu eine bereits prinzipiell taugliche Parameterkombination, die man dann ein bisschen besser und/oder robuster machen will.

Für diese Art der Suche müsste ich meinen Backtest umfangreich umschreiben, weswegen ich derzeit einen einfacheren Weg gehe: Ich suche mir die jeweilige Parameterkombination pro Optimierungszeitraum über mehrere Kennzahlen aus, d.h Sharpe Ratio, maximaler Drawdown und Endvermögen, die in einem vernünftigen Verhältnis stehen müssen. Da Drawdown und Endvermögen normalerweise Antipoden sind, hoffe ich, dass bei einem vernünftigen Verhältnis aller Kennzahlen auch eine taugliche Kombination heraus kommt.

 

Es wird alles nicht funktionieren. Was Du da machst ist wirklich kalter Kaffee. Vor ca. 15 Jahren hat schon Tradestation sowas eingeführt. Da haben dann die Leute unendlich viele Parameter durchgerechnet und ausprobiert und optimiert, auch ich. Ergebnis, ist der falsche Weg. Bringt sowas von nix.

Es gibt andere Dinge die im Crypto wesentlich wichtiger sind und zu besseren Ergebnissen führen.

 

 

 

[PeWi]

On 9/13/2023 at 5:57 PM, Chantal Krüger II said:

Da haben dann die Leute unendlich viele Parameter durchgerechnet und ausprobiert und optimiert, auch ich. Ergebnis, ist der falsche Weg. Bringt sowas von nix.

Das klingt aber eher so, als hätte jemand gehofft, dass der WFO-Backtest der Strategie einen Edge beibringt. Das kann natürlich nicht funktionieren und ist natürlich der falsche Weg.

Auch Kevin Davey betont in seinem Buch "Building Winning Algorithmic Trading Systems" immer wieder, dass die jeweilige Strategie von Haus aus einen Edge haben muss. Wenn der nicht da ist, bringen alle nachfolgenden Schritte auch nichts.

[Chantal Krüger II]

12 hours ago, PeWi said:

Das klingt aber eher so, als hätte jemand gehofft, dass der WFO-Backtest der Strategie einen Edge beibringt. Das kann natürlich nicht funktionieren und ist natürlich der falsche Weg.

Auch Kevin Davey betont in seinem Buch "Building Winning Algorithmic Trading Systems" immer wieder, dass die jeweilige Strategie von Haus aus einen Edge haben muss. Wenn der nicht da ist, bringen alle nachfolgenden Schritte auch nichts.

Aus heutiger Sicht, ist es für mich ein Fehler, einen Edge für eine Strategy zu finden, von daher sehe ich Dein Statement als Unfug an. Den gibt es mit den neuen Techniken wie AI nicht mehr. Weil wenn ich z.B aus den Preisdaten einen Edge finde, dann findet der nächste einen Gegenedge innerhalb von Minuten, Besonders in Crypto kann man das in den Teilen mit nicht liquiden Coins sehen und Muster suchen. Die Tools sind alls so mächtig und für jeden zugänglich geworden. No point.

Ich halte Dein Buch, wie viele andere, für nutzlos, selbst wenn ich es nicht gelesen hab, Das sind alles Tips von vor 10-20 Jahren. Besonders Indikator basiertes Trading im Crypto hat seine eigenarten, z.B. es gibt Phasen, wo der Indikator absolute nicht funktioniert. Dies Phasen muss man identifizieren und filtern.

Backtests machen Sinn, um zu sehen, wie eine Strategie sich verhält und wie man die Equitykurve so hinbekommt, dass man sie optimieren kann. Aber das Problem ist auch, dass die Auflösung von Backtests oft wirklich schlecht ist. Bedeutet, wenn ich auf H1 mit Limits arbeite, muss ich eine Auflösung der Preise auf Tick level im Test haben, das machen viele Plattformen nicht, interpolieren oder machen es gleich ganz falsch. Die Ergebnisse kann ich mir dann knicken. Ich hab das mal selber probiert zu programmieren, aber das ist nicht ohne. Tradestation hat sehr lange gebraucht bis das gut lief. Ein weiterer Faktor ist, wenn man in Instrumenten traded, die nicht dem Konto Basiswert entsprechen, dann muss jedesmal noch korrekt umgerechnet werden.

Von daher bin ich schon vor Jahren dazu übergegangen, eine Strategy zu definieren, die die Entrys und Exits definiert, die sicher funktioniert, auch in schnellen Märkten, um dann durch eine Art Regelsystem mit der Positionsgrösse aus Regelvariable das System im profitablen Bereich zu halten. So wie eine Heizungsregelung, wo ich eine Temperatur vorgebe, die der Raum haben soll. Das ist das direkte Ergebnis, wenn man das Tharp Buch versteht und umsetzt. Ich hab die Ideen aus dem Tradestation Forum und das hat bisher am besten funktioniert. Da muss ich nix gross optimieren.

[PeWi]

So eindeutig ist es wohl nicht, wie du es hier schreibst.

Die Firma hinter dem Tradingsystem "Zorro" programmiert seit Jahren Systeme nach Kundenvorgaben und haben nach über 1000 entwickelten System mal den Erfolg nach Systemtypen ausgewertet:

It is also a bit surprising that the most complex systems of all, the data mining systems that usually employ deep learning algorithms, did not fare much better. They have an acceptable success rate, but are easily surpassed by a certain sort of much simpler systems. 

Im Berereich Krypto-Systeme waren die Erfolgschancen so:

Market model  75%,   Data mining 62%,    Indicator soup 25%

(Das gibt dir aber dahingehend recht, dass Indikator-Systeme im Normalfall nichts taugen.)

https://financial-hacker.com/please-send-me-a-trading-system/

 

[PeWi]

Nachtrag:

Ich muss das oben geschriebene zu den Indikator-Systemen relativieren.

Unter "Indicator soup" versteht der obige Artikel nicht allgemein Indikator-Systeme, sondern irgendwelche wilden Zusammenwürfelungen, bei denen man keinen Sinn und Zweck erkennen kann.

"Normale" Indikator-Systeme, d.h. solche zur Trendverfolgung oder Mean Reversion etc, werden von den Verfassern des Artikels mit unter die (erfolgreichste) Kategorie "Market models" einsortiert.

Market model systems exploit a particular market inefficiency by detecting anomalies in price curves. Trend following, mean reversion, market cycles, statistical arbitrage, or HFT arbitrage are typical model based trade methods.

Data mining systems predict a price trend by evaluating signals with a machine learning algorithm. Those signals are usually derived from the order book or the price curve, but sometimes also from fundamental data or exotic data sources.

Indicator soups do not target a particular market inefficiency. They generate trade signals from a complex combination of traditional or newly invented and fashionable indicators, with no recognizable concept or idea behind.

[Chantal Krüger II]

1 hour ago, PeWi said:

So eindeutig ist es wohl nicht, wie du es hier schreibst.

Die Firma hinter dem Tradingsystem "Zorro" programmiert seit Jahren Systeme nach Kundenvorgaben und haben nach über 1000 entwickelten System mal den Erfolg nach Systemtypen ausgewertet:

It is also a bit surprising that the most complex systems of all, the data mining systems that usually employ deep learning algorithms, did not fare much better. They have an acceptable success rate, but are easily surpassed by a certain sort of much simpler systems. 

Im Berereich Krypto-Systeme waren die Erfolgschancen so:

Market model  75%,   Data mining 62%,    Indicator soup 25%

(Das gibt dir aber dahingehend recht, dass Indikator-Systeme im Normalfall nichts taugen.)

https://financial-hacker.com/please-send-me-a-trading-system/

 

Sagen wir mal so, es ist wirklich so eindeutig.

Nach über 1000 entwickelten Systemen : Das sagt sowas von gar nix aus.

Tradestation hat über 100.000 entwickelte Systeme. MT weiss ich nicht, aber dort habe ich allein 2000 Systeme auf eine CD. Ich schätze noch wesentlich mehr als TS. Ich finde es sehr kritisch, wenn Systemlieferanten Auswertungen machen. Die wären bei mir sofort vom Tisch.

Nach Kundenvorgaben heisst nur, die haben Kunden, die das selber nicht gebacken bekommen haben und Subcontraktor genommen haben. Ja, kann man machen, ich habe bisher noch nie gesehen, dass dies wirklich funktioniert. Mehrnoch, wer stellt sicher, dass sich der Subcontraktor nicht damit selber Einkommen sichert und der Programmierer privat das ganze selber nutzt ?

Auswertung der Systeme, da fange ich an, noch kritischer zu werden. Ich sehe diese Zahlen als Unsinn an.

1. Indikatorsysteme sind oft eine Reflektion von Marktmodellen. Wie wird da unterschieden ? 

2. Es gibt nach meiner Erfahrung kein Indikstorsystem, welches nur aufgrund der Entry/Exit Signale durchgehend funktioniert. Das ist allein dadruch bedingt, dass die Märkte sich unterschiedlich ändern. In Crypto kommen noch andere Punkte hinzu. 

3. Punkt 2 ändert sich signifikant, wenn ich eine Filtersystem entwickel (da gibt es dann unterschiedliche Ansätze), wann das jeweilige Indikatorsystem funktioniert. Sehr oft gehen die dann durch die Decke.

4. Der Hauptschwerpunkt ist wirklich das "Wie viel" und nicht das wann. Dies ist bei Marktmodellen und Indikatormodellen genau das gleiche. Sowas kann man sehr einfach bei Backtests und Betrachtung der Equitykurven zeigen.

https://financial-hacker.com/please-send-me-a-trading-system/

Zu den Erklärungen dort, was die einzelnen Modelle sind, wage ich stark zu bezweiflen, dass dies korrekt ist. Ist aber auch egal. Ein gutes System verdient Geld, der Rest ist mir ziemlich egal.

Wenn jemand ein System hat, kann man es sehr oft auch sehr einfach profitabel machen. Und wenn er ein profitablems System hat, sollte er es selber umsetzen und nicht irgendwo verkaufen oder publizieren. Weil es geht dann um sehr viel Geld und da hat man keine Freunde. Leute werden irgendwann gierig.

Zusätzlich sehe ich die angegebenen Daten in der Performance Tabelle sehr kritisch. Es kommt auf das zu testende System an und wie die Werte bei Backtests ermittelt werden. Die Varianzen des Mappings sind bei einigen Systemen so gross, dass man es einfach vergessen kann.

Also, netter Artikel sagt aber nix aus.

Bearbeitet 15. September 2023 von Chantal Krüger II

[PeWi]

On 9/13/2023 at 11:02 AM, PeWi said:

Was ich bisher nicht eingebaut habe, ist das beim Tradingsystem "Zorro" beschriebene Aussuchen einer robusten Lösung, d.h. einer, deren Parameter aus einem Plateau stammen. So, wie ich die Beschreibung bei "Zorro" verstanden habe, braucht man dazu eine bereits prinzipiell taugliche Parameterkombination, die man dann ein bisschen besser und/oder robuster machen will.

Für diese Art der Suche müsste ich meinen Backtest umfangreich umschreiben, weswegen ich derzeit einen einfacheren Weg gehe: Ich suche mir die jeweilige Parameterkombination pro Optimierungszeitraum über mehrere Kennzahlen aus, d.h Sharpe Ratio, maximaler Drawdown und Endvermögen, die in einem vernünftigen Verhältnis stehen müssen. Da Drawdown und Endvermögen normalerweise Antipoden sind, hoffe ich, dass bei einem vernünftigen Verhältnis aller Kennzahlen auch eine taugliche Kombination heraus kommt.

In den letzten beiden Wochen habe ich den WFO-Backtest weiter ausgebaut.

Das Herausfischen einer "sinnvollen" Kombination der Kennzahlen ist jetzt ein bisschen "intelligenter" geworden. Dadurch ist bei meinen Tests auch das OOS-Testendergebnis ein Stück besser geworden, weil jetzt bessere Parameterkombinationen selektiert werden.

DIe letzten Tage ist noch ein einfacher Robustheitstext dazugekommen. Die guten Ergebnisse werden leicht verrauscht und ebenfalls durchgerechnet. Das ursprüngliche Parameter Set sollte dabei nicht viel besser als in der Mitte der Streubreite der Variationen liegen, sonst wird es als zufälliger Glückstreffer verworfen.

Ob dieser Robustheitstest die Ergebnisse ebenfalls verbessert, muss ich erst noch sehen. Da dieser Test erst heute Nacht fertig geworden, habe ich noch keine Erfahrungswerte.

[PeWi]

Nachdem ich den gleichen Backtest fünfmal mit und fünfmal ohne Robustheitstest habe durchlaufen lassen, steht fest, dass sich dieser zusätzliche Test lohnt:

Ohne Robustness-Test

- Final balance 3749.700€, ATH 5285.320€, MaxDD 29.1%, ratio 1.490, proffac 1.85, ulcer 14.50, kelly 0.18
- Final balance 3009.269€, ATH 4653.506€, MaxDD 35.3%, ratio 1.239, proffac 1.64, ulcer 17.38, kelly 0.13
- Final balance 3730.317€, ATH 5269.873€, MaxDD 29.2%, ratio 1.492, proffac 1.85, ulcer 14.57, kelly 0.18
- Final balance 3023.036€, ATH 4667.428€, MaxDD 35.2%, ratio 1.242, proffac 1.65, ulcer 17.32, kelly 0.13
- Final balance 2991.736€, ATH 4636.318€, MaxDD 35.5%, ratio 1.232, proffac 1.64, ulcer 17.43, kelly 0.13

Mit Robustness-Test

- Final balance 4179.206€, ATH 5667.682€, MaxDD 26.3%, ratio 1.626, proffac 2.10, ulcer 13.41, kelly 0.20
- Final balance 3932.084€, ATH 5255.205€, MaxDD 26.9%, ratio 1.562, proffac 2.02, ulcer 14.28, kelly 0.18
- Final balance 3420.951€, ATH 4643.124€, MaxDD 28.6%, ratio 1.285, proffac 1.80, ulcer 15.06, kelly 0.17
- Final balance 4250.937€, ATH 5542.350€, MaxDD 25.0%, ratio 1.745, proffac 2.11, ulcer 13.06, kelly 0.22
- Final balance 3893.868€, ATH 5371.865€, MaxDD 31.4%, ratio 1.527, proffac 1.84, ulcer 16.00, kelly 0.18

Die Ergebnisse variieren natürlich, weil der Backtest seine Parameterkombinationen zufällig aus dem möglichen Parameterraum zieht.

Im Schnitt liegen die Ergebnisse mit Robustheitstest merklich besser.

 

[Chantal Krüger II]

22 hours ago, PeWi said:

Nachdem ich den gleichen Backtest fünfmal mit und fünfmal ohne Robustheitstest habe durchlaufen lassen, steht fest, dass sich dieser zusätzliche Test lohnt:

Ohne Robustness-Test

- Final balance 3749.700€, ATH 5285.320€, MaxDD 29.1%, ratio 1.490, proffac 1.85, ulcer 14.50, kelly 0.18
- Final balance 3009.269€, ATH 4653.506€, MaxDD 35.3%, ratio 1.239, proffac 1.64, ulcer 17.38, kelly 0.13
- Final balance 3730.317€, ATH 5269.873€, MaxDD 29.2%, ratio 1.492, proffac 1.85, ulcer 14.57, kelly 0.18
- Final balance 3023.036€, ATH 4667.428€, MaxDD 35.2%, ratio 1.242, proffac 1.65, ulcer 17.32, kelly 0.13
- Final balance 2991.736€, ATH 4636.318€, MaxDD 35.5%, ratio 1.232, proffac 1.64, ulcer 17.43, kelly 0.13

Mit Robustness-Test

- Final balance 4179.206€, ATH 5667.682€, MaxDD 26.3%, ratio 1.626, proffac 2.10, ulcer 13.41, kelly 0.20
- Final balance 3932.084€, ATH 5255.205€, MaxDD 26.9%, ratio 1.562, proffac 2.02, ulcer 14.28, kelly 0.18
- Final balance 3420.951€, ATH 4643.124€, MaxDD 28.6%, ratio 1.285, proffac 1.80, ulcer 15.06, kelly 0.17
- Final balance 4250.937€, ATH 5542.350€, MaxDD 25.0%, ratio 1.745, proffac 2.11, ulcer 13.06, kelly 0.22
- Final balance 3893.868€, ATH 5371.865€, MaxDD 31.4%, ratio 1.527, proffac 1.84, ulcer 16.00, kelly 0.18

Die Ergebnisse variieren natürlich, weil der Backtest seine Parameterkombinationen zufällig aus dem möglichen Parameterraum zieht.

Im Schnitt liegen die Ergebnisse mit Robustheitstest merklich besser.

 

Und was genau soll das nun bringen ?

[PeWi]

3 hours ago, Chantal Krüger II said:

Und was genau soll das nun bringen ?

Gnadenlos wie immer ...

Steht ausführlich in diesem Thread, wenn du ein bisschen zurückblätterst.

Und außerdem aus Spaß an der Freude, weil das einfach interessant und spannend ist.

[Chantal Krüger II]

1 hour ago, PeWi said:

Gnadenlos wie immer ...

Steht ausführlich in diesem Thread, wenn du ein bisschen zurückblätterst.

Und außerdem aus Spaß an der Freude, weil das einfach interessant und spannend ist.

Aber diese Backtests können die Zukunft nicht vorhersagen. Es ist also nutzlos und Du beschäftigst Dich mit nutzlosen Dingen.

Was bringt es also ?

Bearbeitet 9. Oktober 2023 von Chantal Krüger II