GeorgM Candletalk - Datenexploration

Datum: 10.8.2014
Letzte Änderung: 10.8.2014, 18:19 UIhr


Autor: Krümel.

GeorgM hat mit Hilfe von PT alias Norbert Gundeler eine Exceltabelle online gestellt, die ich mir als Ascii runtergeladen (bzw. rauskopiert)  habe und mal einige Untersuchungen anstellen möchte.

In[1]:=

In[2]:=

Out[3]=

In[5]:=

Ich plotte mal für einen ersten Überblick die 2 mMn wichtigsten Spalten Volatility versus G/V:

In[8]:=

Out[8]=

In 2 D gefällt mir das nicht so gut,da die Punktewolken keine echten sind, sondern auf den Vola-Werte zu sehr verschmiert. Der Listplot ist daher nicht so gut geeignet.


Ich schau mir das daher in 3-D an, da sieht man auch die Anzahl pro Kombination/ Wertepaar Vola/GV.

In[9]:=

Out[9]=

Für die höheren Vola-Werte hat man eindeutig zu wenig Daten, für die niedrigen Volawerte sieht es eher nach 2 ineinanderverschobenen Verteilungen pro Vola-Rasterpunkt aus. Theoretisch könnte man da einen Stopp reinpacken und so die ollen Verluste vermeiden. Praktisch kann ich das leider nicht machen, da ich nicht weiß, wie groß Intraday der Buchverlust geworden ist, bevor das Tagesergebnis generiert wurde. Da ich auch nicht weiß, wie das Tagesergebnis zustandegekommen ist (ein oder mehrere Trades), lassen sich an der Stelle keine weiteren Ideen ableiten, da mir die Informationen fehlen.


Ein einfaches vola-unabhängiges Histogramm zeigt etwas ähnliches:

In[10]:=

Out[10]=

Irgendwie verleitet diese mehrgipflige Verteilung zum Abschneiden links. Geht aber leider nicht, da keine Informationen über Intratrade-Drawdowns vorliegen. Muss also ohne weitergehen *grummel*.
Aber der Erwartungswert ist tatsächlich positiv ? Oder ?

In[11]:=

Out[11]=

Ok, 50% aller Werte sind kleiner gleich 0. Die 0 trennt perfekt, tzz, das findet man so auch selten. Der Mittelwert dürfte aber leicht rechts verschoben sein, der sackt ja regelmäßig in die Richtung vom Verteilungspeak.

In[12]:=

Out[12]=

Na ja, 6,6 Punkte ist ja besser als nichts. Man müsste es schaffen, die dicken Verluste links abzuschneiden, die Verteilung sieht so schlecht gar nicht aus. Ich schau mal weiter...

Kumulierte Dichteverteilung ( zum Nachlesen, was man daraus ableiten kann : http://www.statistics4u.info/fundstat_germ/cc_cumulative_frqdist.html  ):

In[13]:=

Out[13]=

Na, da sieht man auch gut, dass 50% aller Tage kleiner/gleich 0 enden.

In[14]:=

Out[14]=

25% aller Werte liegen unter -70, 50% liegen unter/gleich 0 (ok, und für Optimisten: 50% liegen über/gleich 0), 25% aller Werte sind größer als 72 Punkte.
Wenn man diie Gebühren mit einrechnet, verschiebt sich das ganz natürlich leicht. Man muss also an der Verteilung links was machen, da kommt man nicht drum herum.  

Anteile Gewinner/Verlierer/0-Tage

Ich suche mal die Gewinner-, Verlierer- und GV-0-Tage raus.

In[15]:=

In[18]:=

Out[18]=

In[19]:=

Out[19]=

In[20]:=

Out[20]=

Gesamtdatenlänge:

In[21]:=

Out[21]=

Jetzt ist die Frage, ob man die 0-Trades aus der Rechnung weglässt oder den “Gewinnern” hinzurechnet. Man kann aber auch gemein sein und den Verlierern hinzurechnen, denn unter Berücksichtung etwaiger Gebühren werden aus den neutralen Werten ja negative (0 minus Gebühren).


Ich bestimme die Prozente mal separat, das ist am fairsten, finde ich. Die 0-Tage kann man streng genommen auch weglassen, denn die tragen weder zum Gewinnteil noch zum Verlustteil was bei, sondern blähen nur künstlich auf.

In[22]:=

Out[22]=

In[23]:=

Out[23]=

In[24]:=

Out[24]=

Wie sieht die Struktur der Handelstagsergebnisse aus ? Erkennt man eine Systematik ?

In[25]:=

Out[25]=

Leider nein, eher die typische Vola-Clusterbildung, die man auch bei normalen Rendite-Untersuchungen vorfindet.  Ist ja doch immer recht auffällig und unterscheidet sich von echten normalverteilten Random-Daten.

Mal zum Vergleich: (ich nehm die Daxdaten mal vorweg (das passt hier aber gut hin, Erklärungen kommen weiter unten)

In[26]:=

Out[31]=

Hmm, sieht nicht nach nem echten Systemvorteil aus verglichen mit nem einfachen Verlauf der Dax-Renditen. Oh weia, da dreht man mir mit Sicherheit im Forum nen Strick draus (“Hängt den Ketzer auf ! Brennen soll er !”). Zum Glück hab ich meinen Account ja löschen lassen. Da können sie mich aus der Ferne hassen. :D



Kumuliert (also Tag für Tag aufgerechnet) ergibt sich dasselbe Bild wie bei trash.

In[32]:=

In[33]:=

Out[33]=

Bei der Darstellung gehe ich von 0 Startkapital aus.

In[34]:=

Out[34]=

In[35]:=

Out[35]=

Endwert:

In[36]:=

Out[36]=

Wenn ich jetzt Georgs Startwert von 2000 Euro ansetze:

In[37]:=

Out[38]=

In[39]:=

Out[39]=

Endwert:

In[40]:=

Out[40]=

Und noch der Plot dazu:

In[41]:=

Out[41]=

Na ja, durch die Konstante verschiebt sich die gesamte Kurve in der Höhe, mehr passiert da allerdings nicht.



Abschließend mal wieder ein Plausibilitäts/Korrektheuitscheck:

In[42]:=

Out[42]=

In der Abbildung ist die rote Linie die von mir berechnete kumulierte G/V-Kurve, und die blauen Punkte sind die aus der von PT gehosteten Tabelle. Passt also.
Man kann aber noch nen Extratest machen, um wirklich sicher zu sein. Bei Differenzbildung beider Kurven muss jeder Wert 0 sein.


Das sieht nach kumulierten Rundungsfehlern aus ?

In[43]:=

Out[43]=

Wo geht die 1 los und was für Werte stehen da in beiden Listen:

In[44]:=

In[45]:=

Out[45]//TableForm=

In der Textdatei findet man an der Stelle:
2012-02-28    23    70    6,055    8,055
2012-02-29    23    140    6,195    8,195
2012-03-01    23    -163    6,031    8,031
2012-03-02    23    89    6,120    8,120
2012-03-05    23    140    6,260    8,260

In[46]:=

Out[46]=

Ok, das ist vermutlich so ein echt mieser subtiler Fehler in den Datenformaten, die hat man zum Glück recht selten. Mal prüfen:

In[47]:=

In[49]:=

Out[49]=

Hmm, das geht auch nicht (Umwandeln in einfache Zahlen statt Symbols), die Unterschiede bleiben.


Also nochmal in die Originaldaten schauen und Old School vergleichen.  Im Google-Spreadsheet stand:

In[50]:=

Out[50]=

Nöö, dann ist es kein Rundungsfehler, sondern in der Tabelle steht tatsächlich ein falscher Wert. Sowas kommt vermutlich noch 2 mal vor, damit kumuliert sich das auf die maximal 3 Punkte Unterschied aus der obigen Liste. Kann auch vom Google erzeugt worden sein, ich weiß ja  nicht, wer die reinkodiert hat.

Solange die Fehler kein größeres Ausmaß annehmen, ist es ja harmlos. Da hab ich schon Datentabellen mit erheblich mehr Fehlern bearbeitet.

Ergänzende Betrachtung durch Hinzunahme der Dax-Kursdaten

Ich nehm’ erstmal den “normalen” Daxperformance-Index aus der Mathematica-Datenbank. Das ist natürlich nicht der korrekte Datensatz, aber als erster Anhaltspunkt sollte es schon mal Ideen liefern, hoffe ich.


Ich benötige dazu Start- und Enddatum, damit ich nur diese Daten gezielt aus der Datenbank abrufen kann. Format: date,O,H,L,C,V,

In[51]:=

Out[51]=

In[52]:=

Out[52]=

Man muss auch das Format des Datums nicht anpassen, das ist ja schon mal schön.

Mal sehen, was beim Dax in dem Zeitraum für Daten drin sind:

In[53]:=

Out[53]=

Na ja, ist ja alles dabei: starke Abwärtsbewegung, kleinere und größere Korrekturen , und auch schöne Aufwärtsbewegungen. Wobei vermutlich die Aufwärtsbewegungen insgesamt dominieren dürften.

Das schau ich mir mal an.

In[54]:=

Out[54]=

Anzahl Handelstage im untersuchten Zeitraum:

In[55]:=

Out[55]=

Zum Vergleich die Anzahl von Georgs Daten:

In[56]:=

Out[56]=

Hmm, da passt ja was nicht.

Ich schau mal, welche Datumsangaben nicht passen (Intersection = Schnittmenge bilden, das ist die Menge, in der die Datumswerte aus beiden Tabellen enthalten sind, dann die Komplementärmenge bilden. Letztere ist die Menge, die alle übrigen Werte enthält, die in einer der beiden Tabellen zuviel drin sind).

Dazu muss ich aber entgültig die Datumsformate angleichen. Ich nehme dafür das Format von Mathematica.

Aus

In[57]:=

Out[57]=

muss also

In[58]:=

Out[58]=

werden.
Und noch die 3 0en hinten entfernen.

In[59]:=

Out[59]=

Schick. Dann muss man das jetzt elementweise auf den Datumswerten aus Georgs Tabelle machen.

In[60]:=

Die ersten 10 Elemente (wegen der Übersichtlichkeit) mal gegenchecken (erste Spalte = orginal, 2. Spalte = umgewandelt)

In[61]:=

Out[61]//TableForm=

Passt.
Nun die Schnittmenge bilden aus Georgs Datumswerten und denen aus dem Dax von Mathematica:

In[62]:=

Out[63]=

Die Menge enthält also 1005  Elemente. D.h. es sind in beiden Tabellen Datumswerte drin (und die dazugehörigen Records), die nicht in der anderen Tabelle enthalten sind.



Welche Datumswerte sind in Georgs Tabelle , aber nicht in der Dax-Datentabelle von Mathematica ?

In[64]:=

Out[64]=

In[65]:=

Out[65]=

23 Werte sind “zuviel”.

Welche Datumsangaben sind in der Mathematica-Datenbank, aber nicht in Georgs Tabelle ?

In[66]:=

Out[66]=

In[67]:=

Out[67]=

Ok, das sind also die üblichen Verdächtigen (Feiertage usw.), aber auch andere Tage.
Hab mal stichprobenartig in der Textdatei nachgesehen, Die Werte fehlen an den Tagen tatsächlich.  Warum ist ja egal, ich kann leider nur nicht die Kursverläufe und Georgs Daten 1:1 aufeinanderpacken. Ich entschließe mich daher, die überhängigen Daten aus beiden Tabellen später zu ignorieren und arbeite nur noch auf den synchronisierten Werten weiter. Kann ja immer mal vorkommen, dass Daten fehlen und es sind ja auch nicht so viele, dass es ins Gewicht fallen sollte (könnte man natürlich auch noch prüfen, aber ich pack das erstmal auf die Todo-Liste mit geringerer Priorität).


In Georgs Liste müssen aber doppelte Datumsangaben enthalten sein, anders kann ich mir die Differenzen in den Listenlängen nicht erklären. Von 1040 bis 1005 fehlen doch 35 Werte und nicht nur 23.
Ich entferne daher die Duplikate und zähle nochmal:

In[68]:=

Out[69]=

Das ergibt jetzt tatsächlich 23.


Welche Werte sind denn betroffen ?

In[70]:=

Out[71]=

Ich habe den Plot mal gemacht, weil die Datentabelle zu lang ist und man sich sonst tot sucht. In der Grafik sieht man die Problemzone viel schneller.

Gezieltes Anzeigen der Werte:

In[72]:=

Out[72]=

Im Juli 2013 sind die Daten also doppelt. Ich vermute mal, da liegt ein Fehler vor, denn im Dax sind genau die Juni-Daten überhängig, in Georgs Liste fehlen die Juni-Daten aber. Vermutlich muss man die korrigieren, ein Teil der Juli-2013-Daten sind eigentlich Juni-2013-Daten. Dann könnte man auch mehr Daten synchronisieren. Ist manuell auch schnell zu erledigen.

Ich verzichte aber mal darauf, denn ich kann nur annehmen, dass die zeitlich früheren die Juni-Daten sind, aber vielleicht ist die Annahme auch falsch. Kann ich also nicht entscheiden, lasse die problematischen Daten lieber insgesamt weg, denn es sind ja nicht soviele.

Synchronisierte Kurs-Handelsttagsdaten

Angeblich hau’n ja die berüchtigten Trendtage zu stark rein, weil man sie nicht im Vornherein erkennen können soll.  Also mal schaun, ob die tatsächlich die Übeltäter sind.
Ich nehme nur die Datensätze, deren Datumswerte in der Schnittmenge enthalten ist.

Nachfolgende Datumswerte werden gelöscht.

In[73]:=

Out[73]=

In[74]:=

Out[75]=

In[76]:=

Out[76]=

In[77]:=

Out[77]=

Jetzt noch Georgs Daten bereinigen um die überhängigen Daten:

In[78]:=

In[79]:=

Out[79]=

In[80]:=

Die Daten kann man jetzt synchronisieren:  

In[81]:=

In[84]:=

Als visueller Test im Plot: High-Low-ranges müssen immer positive Werte haben, da der High-Wert immer größer/gleich dem Low-Wert ist.

In[85]:=

Out[85]=

Ok, die Berechnung der Ranges war gut, keine negativen Werte. Ansonsten sieht das komisch aus. Wobei die dicken Verluste tatsächlich mehrheitlich von den High-Range-Tagen generiert werden.


Ich plotte das auch nochmal gegen die Close-Open-Differenz (diese kann natürlich auch negative Werte annehmen):

In[86]:=

In[87]:=

Out[87]=

Wenn man die absoluten Beträge der Open-Close-Range nimmt:

In[88]:=

Out[89]=

... dann sieht man auch hier, dass die dickeren Verluste bei den Tagen mit den größeren Ranges auflaufen. Eigentlich ist das ja sowieso naheliegend *kopfkratz*, irgendwo müssen die Punkte ja herkommen, da das ja eher eine Wenig-Trades-Am-Tag-Strategie ist.

Und in 3 D kann man erkennen, dass die Fälle zwar nicht sehr häufig vorkommen, aber anscheinend dennoch es schaffen, die Performance zu zerbröseln. Das ist die Sache mit dem Minigrößen bei domestizierten Säugern und Vögeln und deren Generierung stickstoffhaltiger Nahrungsverwertungsüberbleibsel.  

In[90]:=

Out[90]=

Wie gut passt eigentlich der Vola-Wert aus Georgs Tabelle auf die "echte" Vola (gemessen in High-Low-Range bzw. Close-Open bzw. Close-CloseVortag).

In[91]:=

Out[91]=

Die Vola-Rasterung in Georgs Daten ist schon recht grob. Mal sehen, ob das in 3 D besser aussieht:

In[92]:=

Out[92]=

In[93]:=

Out[93]=

Hier drängt sich doch eher ein Box-Whisker-Chart auf:

In[94]:=

In[96]:=

Out[97]=

PT steht ja so auf die Violin-Charts. Dann soll er sie haben ^^:

In[98]:=

Out[98]=

Der Vola-Wert, den Georg zeigt tatsächlich auch einen  Zusammenhang zu den empirischen Vola-Werten.  Wenn man im obigen Plot eine Linie quer durchlegen würde, hätte die tatsächlich einen leicht positiven Anstieg. Allerdings ist die Varianz doch ganz schön groß.


Mal den Fit einer solchen Linie probieren (ich nehme im ersten Anlauf auf Gründen der Einfachheit an, dass der Zusammenhang tatsächlich linear ist, muss jedoch nicht sein !):

In[99]:=

Out[99]=

In[100]:=

Out[100]=

Das Vola-Maß ist also gar nicht so schlecht, zumindest im Mittel.... Es streut halt stark, aber eh man gar nichts hat....

[To be continued.... aber nicht unbedingt von mir, ich hab grad akut keine Lust mehr.]

Created with Wolfram Mathematica 8.0