Beurteilung von Handelssysteme mit einer Zahl

=> "Fröhlich"-Faktor
da ist alles obengenannte drin und er eignet sich daher aus meiner Sicht mit am besten zum Vergleich von verschiedenen Intradaysystemen jeglicher Art.

Zum Vergleich von längerfristigen bis EOD Systemen mit aktiven puren Intraday-Systemen, sollte man den Faktor auf "Tageserträge" normieren und dann mit den Ergbnissen der langfrist/EOD Systeme vergleichen. Hauptaugenmerk muss hier dann auf das richtige Verhältnis aus Ertrag und benötigter Kapitalbindung gelegt werden!

Bei reinen EOD Systemen würden ich zur sicheren Bestimmung der nötigen Kapitalbindung hier max. Draw-Down und max. Verlustserie höher gewichten, aber das interesiert mich selbst nicht.

Als vereinfachte grafische Lösung für den Vergleich von "Kapitalkurven", bei denen man wenig/nix über die Systeme weiss, mach ich notfalls folgendes:

1. man zeichne eine lineare Regressionsgerade ein, bzw. notfalls auch einfach Anfangs und aktuellen Endpunkt der Kapitalkurve verbinden.
2. man bestimme den Steigungswinkel der Gerade (+90°..-90°)
3. man bestimme den max. lotrechten Abstand eines Punktes der Kapitalkurve zu dieser Linie
4. man teile Winkel/(Abstand+1)

Wenn man das für mehrere Kurven macht, "gewinnt" bei mir die mit dem größen sinnvollen Ergebnis. (Im Idealfall einer "störungsfreien" glatten Steigung ohne Abweichung käme ja der Winkel selbst heraus. Das gibt es aber praktisch nicht, sodass ein Ergebnisse sehr nah am Winkel ein mahnendes Zeichen sind)

@ TimeTrade [#3]

Könnte man anstatt Deiner Vorgehensweise in #3 nicht gleich R² nehmen und damit die verschiedenen Kapitalkurven vergleichen? Der höchste R² gewinnt...
(Der Vorteil Deiner Variante ist vermutlich die Einbeziehung des Winkels, oder?)

Zur Systembeurteilung führe ich oft einen einseitigen t-Test durch. Hierfür ist eine Grundvoraussetzung, dass die Daten (Renditen) normalverteilt sind, was natürlich bei Renditen der Handelssysteme oft nicht der Fall ist.

MfG

@all,

ein alternativer Ansatz:

1. ich führe für die Handelssysteme einen Stresstest mittels Monte Carlo Simulationen durch (Input für die MCS sind vorhandene Systemreportkennzahlen aus den konventionellen Systemtests, die z.B. Metastock liefert)

2. die MCS liefert bezogen auf die durchgeführten Simulationsläufe min., durchschnittliche sowie max. Profite je Zeiteinheit und ebenso min., durchschnittliche und max. (Acount-)Drawdowns

3. Zwei theoretisch daraus abgeleitete Kennziffern, das Average Cost Ratio ACR(Verhältnis durchschnittl. Profit zu durchschnittl. Drawdown) und insb. das Worst Case Ratio WCR (Verhältnis min. Profit zu max. aufgetretenem Drawdown) ermöglichen einen Vergleich von Handelssystemen

Weitere Infos unter http://www.zentrader.de

ciao,
zentrader

@ kanada [#4]

im Prinzip geht auch R², nur nutze ich diese Methode wie beschrieben wirklich nur für eine schnelle einfache überall/jederzeit mögliche manuelle Beurteilung, eben für eine erste Aussage zu Kapitalkurven wenn mir mal wieder jemand etwas zeigt und mein "Gefühl" wissen will. (Der Winkel sagt bei vergleichbaren Zeitachsen etwas zum Realertrag über die Zeit)

Wenn ich technische Handelsdaten/Kennzahlen habe, dann nutze ich andere Sachen um für mich zu einer Bewertung zu kommen ;)

@ TimeTrade [#6]
Danke für Deine Antwort.

@ zentrader [#5]

Ich wage zu bezweifeln, dass man durch MC-Simulation einen besseren Einblick ins System erhält. Es wird ja angenommen, dass die verwendeten Systemkennzahlen auch in Zukunft das jeweilige System exakt beschreiben, was natürlich bei Handelssystemen keiner garantieren kann.

Wendet eigentlich jemand das Bootstrap-Verfahren an, um die Verteilung der Renditen zu schätzen bzw. hat jemand damit Erfahrung?

@kanada,

korrekt. Der "Monte Carlo Simulations"-basierte Stresstest von Systemreport-Ergebnissen kann sich nur auf den jeweiligen Zeitraum des Systemtests beziehen. Trotzedem kann ich damit Handelssysteme vergleichen.

Um dieses Problem der Robustheit von Handelssystemen unter geänderten Marktbedingungen (d.h in unterschiedlichen Zeiträumen) anzugehen, verwende ich zusätzlich eine als "Datensimulation" bezeichnete Generation von synthetischen Daten. Diese Daten werden aus der historischen Originalzeitreihe erzeugt, jedoch durch "Monte Carlo Simulations"-basierte Zufallskomponenten in ihrer zeitlichen Verteilung neu gemischt und zusätzlich durch vom Anwender steuerbare Szenarien (z.B. mehr/weniger Volatilität, Musterbeibehaltung etc.) beeinflusst. Mit diesen künstlichen Daten werden nun wieder Systemtests mit z.B. Metastock gemacht und die Systemreportergebnisse kann ich nun erneut in den o.g. MCS-basierten Stresstest ("systemsimulation") einfliessen lassen.

So kann ich ein Handelssystem durchaus unter möglichen unterschiedlichen (natürlich aufgrund der unendlichen Möglichkeiten nicht unter allen) Marktbedingungen testen und bekomme auf jeden Fall eine bessere Validierung des Systems als ohne MCS... :-)

ciao,
zentrader

@ zentrader [#8]

Hallo zentrader,

finde an deinem Produkt die Erstellung synthetischer Daten interessant.
Ist es möglich aus einer vorgegebenen Historie gleich mehrere
neue Datein zu erstellen?
Also auf einen Schlag 100 oder 1000 neue Historien?

(@ All: Ich will hier keinen Streit über Sinn oder Unsinn vom Zaun brechen!)

Grüße,
dansmo

@ helmer [#1]

Hat schon jemand mal versucht Handelssysteme anhand einer einzigen Zahl zu
vergleichen.

ist das nicht der Fröhlich-Faktor den Hr. Fröhlich im Jahre 2003 veröffentlichte um eine Kennzahl zur Messung der Güte von Handelssystemen zu haben.

Beste Grüße

Roti

@ dansmo [#9]

aktuell können max 100.000 Dateien mit jeweils max. 100.000 Datensätzen in einer Transaktion (OK-Button in der EXE-Version, bzw. als Funktionsaufruf in der DLL-Version) erstellt werden.

Wenn's denn die Hardware verkraftet... :-)

ciao,
zentrader

@ Roti [#10]
"ist das nicht der Fröhlich-Faktor..."

... siehe @ TimeTrade [#2] ;-)

Schönen Dank an alle,

habe mal gesucht wie sich der Fröhlich-Faktor zusammensetzt und habe dabei folgende Formel gefunden:

[Performance * PW * (ProfitFaktor + AW / AL) ] /
[max. Einbruch + max. Verl.Trade + maxGew.Trade]

mit:
PW = Anteil Gewinner
AW = mittlerer Gewinn
AL = mittlerer Verlust

Gruß

helmer

@ helmer [#1]

wie wär's mit der sharpe ratio?

bd

habe mal gegoogelt was das sharpe ratio ist:

Diese Kennziffer gibt Aufschluss darüber, ob und inwiefern eine Mehrrendite unter Einbeziehung des Risikos (Volatilität) im Vergleich zu einer risikolosen Geldmarktanlage erwirtschaftet wurde.

Da stellt sich für mich die Frage, wie ich dieses Risiko in einer Zahl greifen
kann.
Es erscheint mir schon wichtig max Einbrüche und ähnliche Risiken miteinzubeziehen.

Gruß

helmer

@ helmer [#15]

'Da stellt sich für mich die Frage, wie ich dieses Risiko in einer Zahl greifen
kann.'

Das Risiko einer Anlage kann durch den Erwartungswert der Renditen und deren Streuung ausgedrückt werden.

Bei identischen Erwartungswerten entscheidet sich der risikoaverse Investor immer für die Anlage, die eine niedrigere Steuung (ausgedrückt durch die Standartabweichung) aufweist.

In das Shape Ratio gehen beide Werte -Erwartungswert der Rendite und Standartabweichung der Rendite- ein.

Bezogen auf Handelssysteme heißt das, dass Systeme die im Zeitablauf gleichmäßige Renditen erwirtschaften risikoloser sind als Systeme, deren erwartet Renditen mehr schwangen, also streuen.

...wenn dich max. Einbrüche und Risiken interessieren, kommst Du um eine Monte Carlo Simulation wohl nicht herum.

Wenn ich mal Talebs Analogie bzgl. des höchst möglichen Risikos (siehe "Narren des Zufalls": der "schwarze Schwan") heranziehe, erkennst Du mit herkömmlichem Back-Testing normale "weisse Schwäne", mit MCS werden Dir je nach Qualität des Simulationsprozesses auch die "grauen bis dunkelgrauen Schwäne" bewusst.

Das Risiko des immer möglichen "schwarzen Schwans" nimmt Dir jedoch niemand ab (auch keine Methode)!

ciao,
zentrader

@ zentrader [#11]

Hallo zentrader,

ich habe mir die Demo mal angesehen und wollte das Erstellen neuer Daten ausprobieren. In den neuen Textdateien kam aber nur der Hinweis:
Zen Monte Carlo Simulator v5.0 Demo-Version...

Ist die Datensimulation in der Demo nicht verfügbar?

Grüße,
dansmo

@dansmo,

richtig.

Die Demo-Version erlaubt nur die Bedienung der Software unter Echtbedingungen (Features, Benutzerfreundlichkeit, Performance etc.), erzeugt aber nur Demo-Output.

Als Beispiel für die Funktion Dateivergleich ist eine historische Datendatei demo.txt und eine daraus simulierte Datei demosim.txt beigefügt.

ciao,
zentrader

@ zentrader [#19]

Okay, klar.
Noch eine Frage hinterher. Vor einer halben Ewigkeit hatte ich mal equity monaco ausprobiert. Dieses würfelt im Prnip die tatsächlichen Trades (oder Tagesergebnisse etc). zig Tausende Male durcheinander und erstellt daraus dann die Grafiken.
Dein Simulator macht das "nur" an Hand von Kennzahlen, oder?
Wo liegt der Vor/Nachteil der beiden Verfahren?

Grüße,
dansmo

@dansmo,

zum generellen Unterschied: der Zen Monte Carlo Simulator bietet sowohl Systemsimulation als auch Datensimulation an. Equity monaco, Tradesim oder andere Produkte nur Systemsimulation...

Um Systemsimulationen zu erstellen, kann man natürlich auch den Weg gehen und tatsächliche Trades benutzen, es ist aber nicht notwendig bzw. bringt keine besseren Simulationsaussagen hinsichtlich des Simulationsziels, nämlich den denkbaren Profit- und Account Drawdown-Schwankungen des Systems, als der Ansatz über Systemreport-Kennzahlen. Letzterer Ansatz hat zudem die Vorteile, mit weniger Aufwand erstellbar zu sein, dass man die Systemsimulation unabhängig von der jeweiligen Systementwicklungssoftware durchführen kann und dass, soweit die Systemreport-Daten vom Anbieter zur Verfügung gestellt werden, zusätzlich sogar auch Systemsimulationen für "Blackbox"-Tradingsysteme durchführbar sind.

ciao,
zentrader

In diesem Leben werde ich nicht mehr verstehen warum man Datensimulation braucht. Es gibt doch Unmengen ECHTER Daten - und diese sind ja irgendwie im MARKT zu stande gekommen. Daten die von einer Maschine gewürfelt werden sehe ich nicht als hilfsreich an.

So, jetzt gehe ich in Deckung bevor zeni einen cruise missile in meine Richtung hijacked...

gruss hans

@ he96 [#22]

Also ich habe vom Bund-Future nur eine Zeitreihe an der ich testen kann. Wieviele hast Du denn? :-)

Simulatoren versuchen eine synthetische Zeitreihe zu erzeugen, die - und das ist wichtig - das Kursverhalten der zu Grunde liegenden Zeitreihe berücksichtigt.

Stell Dir vor, zufällig steigt der Markt Montags immer. Mal 50 Punkte, dann 43, 74 oder nur 4. Deine olle TradeStation wird dieses zufällige Muster erkennen und Dir eine wunderbare Equitycurve auf Deinen Bildschirm zaubern.

Der Simulator analysiert die Zeitreihe und erkennt, daß es in dem zu simulierenden Kursverlauf, einen Wochentag gibt, an dem der Markt immer steigt. Jetzt vertauscht er heimlich Montag mit Freitag (so Gemeinheiten sind am Markt ja üblich) und schaut sich an, wie sich Dein an die Zeitreihe angepasstes Superhandelssytem, verhalten wird.

Erkennt es den Tausch, und geht nun Freitags long, dann iss gut, wenn nicht: Gehe zurück auf Los. :-)

@he96,

Zen ist per se friedlich und ich bin es meist auch...:-)

Natürlich kann man seine Systemansätze mit anderen Marktdaten testen. Dieser Ansatz ist ja schon mal besser, als nur unter Betrachtung eines historischen Datensatzes vom Backtest in den realen Handel zu wechseln.

Dies hat jedoch (wie auch von wuelle bereits angesprochen) m.E. zwei wesentliche Nachteile:

1. spiegeln auch die anderen Marktdaten oft nur den gleichen zeitlichen (historischen) Betrachtungsraum des Marktes wieder

2. sind Testdaten aus anderen Märkten nicht unbedingt zielführend, um ein bestimmtes Handelssystem, welches eventuell in einem bestimmten Markt etwas besser funktioniert als in anderen Märkten, zu testen

Ich habe im Zen Monte Carlo Simulator deshalb die Datensimulation wie folgt konzipiert:

- Ausgangsdatei ist die historische Originaldatei des Marktes bzw. Instruments, welches ich handeln möchte

- d.h. gewisse Eigenschaften dieser Zeitreihe werden beibehalten (relative Abstände der OHLC-Daten), die Zeitreihe aber insgesamt per Zufallskomponente neu "gemischt"

- durch eine zusätzliche (optionale) Konfiguration kann der Anwender weitere Einflussgrössen bei dieser Datensimulation ins Spiel bringen (z.B. Beachtung der absoluten Grenzen der Zeitreihe, Volatilität, Anteil der up-/down-Kurse, statische und dynamische Kursblöcke etc.), welches aktuell insg. 16 Methoden ergibt, mit der Software synthetische Daten zu erzeugen

Meinem aktuellen Kenntnisstand entsprechend bin ich der Meinung, das eine solche Datensimulation wesentlich mehr Praxisbezug und damit Nutzen im Systementwicklungsprozess aufweist als der o,g, Ansatz einfach weitere historische Daten zu verwenden oder der Ansatz, komplett zufällige Zeitreihen (ohne Bezug zu den Originaldaten) zu erzeugen.

Only my two cents...

ciao,
zentrader

@ wuelle [#23]

""Also ich habe vom Bund-Future nur eine Zeitreihe an der ich testen kann. Wieviele hast Du denn? :-)""

Wenn man 5,10 oder 15min bars nimmt, hat man schon ne Menge verschiedene Kontrakte die man durch die Mühle drehen kann. Bei DAILY ist das natürlich schon weniger, aber da kann man sich auch die Reihen ein wenig aufteilen in "ein paar Jahre".

Daneben würde ich dann noch VERGLEICHBARE Produkte ansehen - d.h. nicht Schweine oder OJ und keine GEWÜRFELTEN Daten.

""die - und das ist wichtig - das Kursverhalten der zu Grunde liegenden Zeitreihe berücksichtigt.""

korrekt - aber das ist ja natürlich KEINE zufällige Zeitreihe mehr.

@ zentrader [#24]

""Ich habe im Zen Monte Carlo Simulator deshalb die Datensimulation wie folgt konzipiert""

ok, hört sich schon besser an als "zufällig" :-))

gruss hans

@he96,

die "hundertprozentige" Zufälligkeit ist ja auch nicht Ziel der Sache, sondern eine Simulation möglicher (eventuell bislang historisch nicht stattgefundener) Marktbedingungen und -zustände. Aber dafür ist die Zufallskomponente (hier im Rahmen einer MCS-gestützten Datensimulation implementiert) eben ein methodisch notwendiger Teilaspekt.

"Zufälle sind unvorhergesehene Ereignisse, die einen Sinn haben"
(Diogenes)

ciao,
zentrader

@ zentrader [#26]

..."Zufälle sind unvorhergesehene Ereignisse, die einen Sinn haben"...

- deine Simulationen beachten nicht die sich "wiederholenden" Zufälle
- Zum Neumischen von Intradaydaten gehört auch die Beachtung von planbaren Daten
- wichtig weiterhin: +/-Tage zum Wochenende, +/- Tage auf Feiertag, EU/US Brückentage, Monatsabhängigkeiten
- aufwendige Systeme, welche solche "konstanten" Faktoren als Regeln verwenden, fallen bei der willkürlichen Mischung von Daten durch, da hierdurch dann die realen Ausnahmen zu oft vorkommen
- deine syntetischen Daten reichen für OHLC-Systeme mit mittleren Zeithorizont, alles was kürzer oder dynamisch agiert und obige Fakten sinnvoll nutzt, wird von solchen Simulationsdaten nicht besser/robuster, sondern verliert das eigentlich vorhandene besondere Potential

Zu den 16 Methoden sollte zur Verbesserung der Datensimulation also noch die Kategorisierung von Zeiträumen kommen, damit dann innerhalb/über diese sinnvoll "zufällig" gewürfelt werden kann.
Eine gute Simulation von echten dynamischen Zeitverhalten der Märkte ist aber wegen der Ausrichtung auf fest gerasterte OHLC-Systeme Systeme trotzdem nicht möglich, denn dazu müssten parallel auch Zeitdifferenzen und Volumen "sinnvoll" simuliert werden.

@timeTrade,

ich gebe Dir insoweit sicherlich Recht, dass die bislang implementierten 16 Methoden nicht das "Ende der Fahnenstange" darstellen. Es sind grundsätzlich beliebig viele Erweiterungen der Simulationsmöglichkeiten denkbar.

Eine aktuell bereits in der Software implementierte Möglichkeit ist die Blockgrösse der Kursanzahl selbst zu konfigurieren (sowohl statisch als auch dynamisch) und durch dieses Verfahren somit auch mehr Eigenschaften der Zeitreihe bzgl. z.B. Abhängigkeiten etc. beizubehalten als bei der Simulation auf Basis von Einzelkursen.

Prinzipiell sehe ich jedoch wesentliche Unterschiede zwischen uns bzgl. des Verwendungszwecks solcher synthetischer Daten:

Wenn ich wie Du sehr viele wiederkehrende Muster, Abhängigkeiten, konstante Faktoren etc. unterstelle, benötige ich eventuell gar keine Datensimulation, sondern beschränke mich gleich auf die bekannten historischen Daten und manipuliere sie eventuell ein wenig manuell nach meinen Erwartungen nach.

Mein Ansatz unterstellt dagegen ein sich änderndes (nicht von mir vorab zu kalkulierendes) Marktverhalten, welches sich durchaus von den historischen Datenzeitreihen unterscheiden kann und gerade unter diesen möglichen neuen (anderen) Marktbedingungen möchte ich ja den Systemeinsatz testen!

ciao,
zentrader

@ zentrader [#28]

Eigentlich interessiert mich nur die Datensimulation.
Beim Dateiformat gibt es nur vier Möglichkeiten. Dabei sind alle Spalten durch Komma getrennt und man kann keine Spalten ignorieren lassen.

Ist geplant hier weitere Möglichkeiten anzubieten? Meine Daten sind bspw. immer durch Tab getrennt und erhalten neben OHLC noch andere Zahlen, die Deine Software dann ignorieren müsste.

Kann man auch nur das Tool zu Datensimulation getrennt von der Systemsimulation kaufen?

Grüße,
dansmo

@dansmo,

ich habe mich im Augenblick auf die 4 üblichsten (Text- bzw. ASCII basierten) internationalen Datenaustauschformate beschränkt.

für EOD:
Format 1: <Ticker>,<Date>,<Open>,<High>,<Low>,<Close>,<optional Volume>
Format 2: <Ticker>,<Per>,<Date>,<Open>,<High>,<Low>,<Close>,<optional Volume>

für Intraday:
Format 3: <Ticker>,<Date>,<Time>,<Open>,<High>,<Low>,<Close>,<optional Volume>
Format 4: <Ticker>,<Per>,<Date>,<Time>,<Open>,<High>,<Low>,<Close>,<optional Volume>

EOD-Daten für Format 1 sehen z.B. so aus:
DaxIndex,07/02/07,6889.12,6904.34,6984.71,6901.25

Ich habe diese Formate wg. Ihrer häufigen Verwendung und leichten Portierbarkeit gewählt, so wird dieses Format 1 z.B. auch vom Metastock Downloader verwendet, um ASCII-Daten nach Metastock EOD zu importieren.

Wenn andere Datenformat vorliegen, bleibt also aktuell nur der Weg zu konvertieren und nach der Simulation zurückzukonvertieren. Ist ja z.B. mit Excel kein Problem (oder mit einem eigenen Konvertierungsprogramm).

Zur letzten Frage:
Es ist ein Produkt, man kann die Datensimulation nicht getrennt kaufen.

ciao,
zentrader

...natürlich prompt ein "gravierender" Fehler drin:

Beispieldatensatz muss natürlich so ausschauen:
DaxIndex,07/02/07,6889.12,6904.34,6884.71,6901.25

:-)

ciao,
zentrader

@ kanada [#7]

"Ich wage zu bezweifeln, dass man durch MC-Simulation einen besseren Einblick ins System erhält. Es wird ja angenommen, dass die verwendeten Systemkennzahlen auch in Zukunft das jeweilige System exakt beschreiben, was natürlich bei Handelssystemen keiner garantieren kann"

Da muss ich Kanada voll zustimmen. Vor allem konnte mir bis dato noch keiner erklären, was ich mit einer Monte Carlo Simulation sehen kann, was ich nicht auch mit Hilfe eines einfachen Taschenrechners oder einem Spreadsheet könnte (von der Datenverfremdung mal abgesehen).

@xForce,

dann versuche ich dies mal zu erklären.

Wenn die Monte Carlo Simulation des Handelsansatzes korrekt implementiert ist, ist solch eine Systemsimulation sicherlich auch mit einem leistungsfähigen Taschenrechner oder einem Spreadsheet durchführbar. Bleiben folgende Fragen zu klären:
1. ist die Implementierung korrekt
2. bin ich in der Lage die richtigen Schlüsse aus der implementierten Lösung zu ziehen
3. genügt die Performance der MC-Implementierung meinen Bedürfnissen hinsichtlich der Entwicklerproduktivität Einen Performancevergleich zwischen Excel und einer schnellen Lösung kannst Du hier auf meiner Website finden:
http://www.zentrader.de/html/monte_carlo_simulator.html

Die Datensimulation ist ungleich komplexer zu implementieren. Mit einem Taschenrechner wird's da wahrscheinlich eng und mit Excel VBA (also einer Spreadsheet Makro Sprache) wird's wohl eventuell mit reichlich Programmieraufwand auch gehen, aber es muss eben erst noch implementiert werden und ist schlicht zu langsam.

Wenn man MCS als wichtige Komponente seines Systementwicklungsprozesses sieht, legt man Wert auf effektive und effiziente Lösungen.

Only my two cents... :-)

ciao,
zentrader

@ zentrader [#33]

Danke für deine ausführliche Antwort, die aber zumindest mir nicht wirklich weiterhilft.

Wenn ich den zu erwartenen Drawdown ausrechnen will an Hand von den Daten durchschnittl. Gewinn/Verlust pro Trade und dem Verhältnis Gewinner/Verlierer dann mach ich das nach wie vor mit nem Taschenrechner oder einem simplen Spreadsheet.

Beispiel ein System mit 500€ Gewinn/300€ Verlust pro Trade. Verhältnis Gewinner zu Verlier ist 45/55. In dem Fall muss ich bei 100 Trades mit 7.7 Verlusttrades in Folge rechnen also ca 2300€ Drwadown. Bei 1000 Trades mit 10 Verlusttrades in Folge sprich 3000€ Drawdown.
ln(1/trades) / ln(%Verlierer)

Mit deiner MC Simulation wirst du auf ähnliche Ergebnisse kommen. Natürlich abhängig vom Pseudozufallsgenerator.

Meines Erachtens werden solche Monte Carlo Simulationen zu hoch bewertet. Die meisten Anwender versprechen sich zu viel davon. Das kann sogar ein falsches Gefühl von Sicherheit vermitteln. Nach dem Motto: meinem System kann nichts passieren, denn ich habe ja per MCS zig Tausend Testläufe gemacht.

Wenn man MCS als wichtige Komponente seines Systementwicklungsprozesses sieht, legt man Wert auf effektive und effiziente Lösungen.

Ich handel einige Systeme (allerdings real und nicht auf dem Papier) und das auch nicht seit gestern. Eine MCS Simulation würde ich bei der Systementwicklung als mit die unwichtigstee Komponente überhaupt einstufen.

mfg

xForce,

danke für die Steilvorlage... :-)

Wenn Du Dein Risiko auf diese Weise ausrechnest, wünsche ich Dir weiterhin viel Glück!

Ich habe Dir mal in der u.s. Grafik den möglichen (Account-)Drawdown für Dein System anhand einer kleinen Systemsimulation beispielhaft dargestellt (angenommen die 100 Trades erfolgen in einem Jahr). Dieses Risk ist ein bisserl mehr als von Dir angegeben und geänderte Marktbedingungen (Stichwort: Datensimulation) sind noch gar nicht berücksichtigt.

Also wenn man weiss, was man tut, schätzt man die Dinge eventuell etwas anders ein.

ciao,
zentrader

@ zentrader [#35]

"danke für die Steilvorlage..."

dito

Was zeigt uns deine Simulation? Einen höheren Max Drawdown. Das ist natürlich kein Wunder, das bei 10000 Simulationsläufen einer dabei ist, der einen hohen Drawdown aufweist.

Je öfter man den MCS laufen lässt, desto größer wird der max Drawdown. Wenn du ihn oft genug laufen lässt, wirst du sicher auch mal über 28.000€ Drawdown haben, sprich fast alle 100 Trades sind Verlierer. Ist zwar sehr unwahrscheinlich aber es gewinnt auch jedes Wochenende einer im Lotto.

Aber du wirst die Sache sicher anders sehen. Das ist wie mit dem Rentenfondmanager, der die ganzen letzten Monate trotz ständig steigender Renditen immer optimistisch war, wenn er zu den Rentenmärkten gefragt wurde. Würde er den Märkten kritisch gegenüberstehen, wäre das schlecht für den Verkauf seines Fonds. Die Hand die einen füttert beisst man nicht...

mfg

xForce,

"...Die Hand die einen füttert beisst man nicht..."

keine Sorge, ich bin nicht "betriebsblind" und mir der Risiken beim Trading trotz (oder gerade wegen) des Einsatzes der Monte Carlo Simulationsmethode sehr bewusst.

"...Das ist natürlich kein Wunder, das bei 10000 Simulationsläufen einer dabei ist, der einen hohen Drawdown aufweist..."

das Problem dieses Systems ist, dass eben nicht nur ein hoher Drawdown auftritt.. :-)

"...Je öfter man den MCS laufen lässt, desto größer wird der max Drawdown..."

das ist mit Sicherheit zwangsläufig eben nicht so. Eventuell war schon die erste der 10000 Simulationen diejenige mit dem max. Drawdown. Und genau dies passiert ja in der Praxis häufig. Man handelt einen gut getesteten, profitablen Ansatz das erste Mal real und läuft gleich in eine Drawdownphase rein, die aber eben nicht ungewöhnlich ist ...

"...Wenn du ihn oft genug laufen lässt, wirst du sicher auch mal über 28.000€ Drawdown haben, sprich fast alle 100 Trades sind Verlierer..."

das ist zwar theoretisch möglich, aber in der Praxis sind die implementierten Zufallsgeneratoren und Algorithmen dann doch nicht ganz so schlecht... :-)

ciao,
zentrader

Hi,

Der Fröhlich-Faktor errechnet sich doch nach:

Fröhlich Faktor = [Netprofit*%WinTrades*(Profitfaktor+durchschnittlicher Gewinn/durchschnittlicher Verlust)]/[Max.Drawdown+maximal (größter) Gewinntrade+maximal (größter Verlusttrade)]

Je höher er ist umso besser. Fröhlich Faktoren über 10 sollen angestrebt werden.

Ich wollte für mein erstes System mal eine Übung machen.
Den Fröhlich-Faktor erechnen.
Obwohl das System auf nicht zum Traden empfohlen wird. Erst recht nicht auf der Short Seite, weil dort die 1:1 Situation nicht gegeben ist. (Wer näheres dazu wissen will frage nach), wollte ich ihn trotzdem für dieses Ruin-System (in meinen Augen) errechnen um ein Gefühl dafür zu bekommen.

Nach Einsetzung der Größen kommt allerdings zu meinem völligen Unverständnis -> 42 heraus. Allerdings habe ich %WinTrades=16,58% eingesetzt d.h. die Prozentzahlen eingesetzt.
Was muss ich einsetzen ? Wenn ich 0,1658 einsetze kommt 0,42 heraus.

Ich vermute dass ich nur die %WinTrades falsch eingesetzt habe. Wer weiss was dazu ?

Netproit -36735,99 %Wintrades in % 16,58 Profitfaktor 0,81 durchschn. Gewinn 575,38 " Verlust -141,15 PV. Drawdown 42376,16 bester Gewinntrade 5647,55 höchs. Verrlusttrade -979,80 Ergebnis 42

na, bin weiter am Überlegen

es kommen weitere Unklarheiten hinzu. Wie geht z. B. der PV Drawdown in die Formel ein ? Positiv/negativ ?

Geht z. B. ein Negativer hergestellter (erzeugter) Netprofit tatsächlich negativ ein ?
Geht der höchst. Verlustrade negativ ein ?

@ Mr_Aegon [#38]

Ich vermute dass ich nur die %WinTrades falsch eingesetzt habe. Wer weiss was dazu ?

Gemäß nachfolgender Formel sollte für %WinTrades 0,1658 eingesetzt werden.

http://wiki.tradesignal.com/de/index.php?title=Fr%C3%B6hlich_Factor

@kanada

Unter http://www.happy-trader.de/fipertec/FF.ppt
wird man irgendwie in einer Präsentation landen u. da steht einiges.

wollen mal sehen ob dein Tip bestätigt wird, und vor allem ob sich Beispiele finden

Danke

@ Mr_Aegon [#43]

Aus genau dieser Präsentation ist mein gepostetes Bildchen :-)

MfG

Konkret ein simples einfaches Beispiel habe ich nicht gefunden.

Die Representation zeigt aber dass:

der durchschnittliche Verlust ist positiv einzusetzen (sonst hätten wir ja negatives Payoff Ratio).
Sicherlich ist der DD als positiv einzusetzen.

Wahrscheinlich hat der Author auch den größten Verlusttrade positiv eingesetzt. (Chande denkt hier ein bißchen anders. Er hätte im Zähler agiert u. dort vernmindert)

Bleibt der Netprofit. Er ist negativ einzusetzen wenn er negativ ist u. positiv wenn er positiv ist.
Bei einem negativen Netprofit wird der Zähler negativ u. damit der FF negativ.
Selbstverständlich erübrigt sich eine Diskussion über dieses System.
(Gigantische 16,5% Trefferquote. Aber das ist ein anderes Thema). Wollte bloß ein Beispiel geben.

ANhand meiner Zahlen müßte deshalb -0,53 rauskommen