Candletalk

Hallo Leute,
ich kämpfe gerade an einem Script, das mir die FxFlat Tradedaten in eine annehmbare Gestalt formatiert. Als erstes möchte ich die - bei FxFlat heißt sie "Kundentranskation Detailbericht" - auflösen. Was nehmt Ihr für Daten aus diesem GFT-Statements? Bei Ergebnissen in einer Handelswährung erfolgt ja die Währungstausch in die Kontowährung erst zu einem späteren Zeitraum. Wartet Ihr erst darauf das die Wertstellung erfolgte? Scheinbar zwacken die immer etwas ab. Auf was ist hier wirklich Verlass? Ich finde das ist total intransparent.
Gruß
OS

P.S.
FxFlat ist ein Introducing Broker von GFT... Die Fragestellung ist ja auch interessant für Leute, die ein Konto bei GFT haben.

Kennt jemand dieses Tool?
http://tradingspreadsheets.com/default.aspx

Benutzt eigentlich jemand so etwas wie "Shape of Trade" bei seinen Auswertungen?

Das sollte doch teilweise sehr mühselig zu erfassen sein, wenn man ca. 10 Trades pro Tag macht, obwohl ich mir hierbei schon einen Vorteil vorstellen könnte, da man so eventuell sehr schön erkennen könnte ob ein Trade, der nicht sofort in Richtung geht vielleicht besser sofort geclosed werden sollte. Auch die Angabe wie weit der Trade vorher in Gegenrichtung gelaufen ist und die Zeit des Gegenlaufs, stelle ich mich sehr arbeitsaufwendig vor.

Hat jemand sich schon mit Traderdna beschäftigt?
http://www.traderdna.com/pdf/examples1.pdf
Die Auswertung nach "Shape of Trade"(ab Seite 4 in der PDF) scheint sehr interessant.

Hallo an alle,

habe den Fehler nun behoben und es nochmal hochgeladen -> http://www.filefactory.com/file/b22gadh/n/TradeStatistics.zip
(In den Verknüpfungen war eine absolute Pfadangabe statt einer relativen )

Eine Möglichkeit ist es in Excel zu exportieren, dort sollten dann weitere Analysen möglich sein(Uhrzeit als Text in seperater Zeile und dann filtern). Und ja, leider habe ich keine Lösung innerhalb des Programms gefunden um nach Zeit zu filtern.

@Remon
In der Tat ein nettes Tool zum Dokumentieren der Trades.
Die Abfrage/Auswertemöglichkeiten scheinen aber halt begrenzt bzw. nur im vorgegebenen Rahmen möglich zu sein.
Anders wäre es, wenn man noch manuell Spalten einfügen könnte, wo man dann zum Beispiel noch Art des Setups, Tageszeit nochmal separat (man kann nur nach Datum aber nicht nach Zeit sortieren) usw. nachträglich eingeben kann. Damit wären individuellere Abfragen möglich.
Leider scheint das Erstellen von eigenen Spalten wie bei Excel nicht möglich zu sein, oder täusche ich mich da?

Versucht doch mal http://www.forexcontrolcenter.com/screenshot.php

Ist umsonst und bietet schon einige gute Möglichkeiten seine Trades auch einzeln mit Bildchen zu dokumentieren.

Hallo janson,

schön das du mich darauf aufmerksam gemacht hast
Hab mal geschaut und gefunden wo der fehler liegt
Werde den Fehler morgen sofort beheben und hier hochladen (ca ab Mittag)

schönen Abend noch und erfolgreiche Woche

Ich habe zwar keine Programmierkenntnisse, fände es aber Klasse wenn dieses Projekt fortgeführt werden würde.
So eine DB, die man mittels SQL abfragen könnte, brächte m.M.n. einen ungemeinen Mehrwert.
Als diskretionärer Trader wäre es toll, wenn man außerdem zu den Trades noch Bilder hinzufügen oder auf Word/Exceldateien verlinken könnte, wo der genaue Tradeverlauf grafisch mit Kommentaren abgelegt wurde.


@mta
Bekomme beim Aufrufen der TradeStatistics.bat Datei die Fehlermeldung, dass Windows die Datei "mapache.exe" nicht finden kann.

Hallo liebe Forengemeinde,
lese hier schon eine ganze weile mit und bin nun auf dieses Thema gestoßen.

Im moment nutze ich PHP, MySQL und JpGraph(für die Diagramme) für meine Auswertung(XAMPP).
Das ganze ist aber echt stupide aufgebaut und auch eher nur für Forex da ich eigentlich nur den EURUSD Trade.

Ich hätte nun große Lust sowas zu realisieren und Aktiv mit daran zu arbeiten und ich hoffe das sich hier noch einige finden werden.

Hier wurde ja schonmal darüber diskutiert was man dafür nehmen könnte (Excel, OO, R, PHP+MySQL, eigene Software, ...)
Ich persönlich fände es am besten wenn wir dazu PHP nehmen würden.

Dafür müsste sich aber der User dann XAMPP Installieren was völlig ungeeignet ist. (zu Overkill, zu Kompliziert)
Man könnte sich auch einen Server mieten und das ganze darauf laufen lassen aber das wäre dann wieder mit Kosten verbunden und ich persönlich gebe nicht gerne meine Daten in irgendeine Webseite ein.

Darauf hin habe ich dann weiter nach einer Lösung gesucht und bin auf MicroApache(http://microapache.amadis.sytes.net/ ) gestoßen.
MicroApache ist ein kleine ApacheWebserver mit PHP5.2, GD2(wichtig für Diagramme) und SQLite.
Vorteile:
Braucht in etwa nur 4MB Speicherplatz
Der User muss nichts Installieren! Er muss sich nur das Archiv runterladen, entpacken und kann dann sofort loslegen.
Wir können mit PHP, GD2 und SQLite arbeiten.

Um euch das mal zu Zeigen habe ich schonmal was vorbereitet.
Es ist ein konfigurierter MicroApache-Server mit 2 Batch-dateien mit dem der User es starten und beenden kann.
Ihr müsst dieses ZipArchive downloaden und an irgendeinem Ort entpacken http://rapidshare.com/files/401371795/Tr…istics.zip.html .
Im Ordner ist nun folgendes enthalten:
Data-Ordner (darin befindet sich MicroApache)
TradeStatistics.bat (damit startet man MicroApache und die Startseite wird im Defaultbrowser aufgerufen [im moment ist es nur eine index.php die Hello, World ausgibt])
Stop.bat (damit kann man MicroApache beenden)

Wie ihr seht ist es für den User dann Kinderleicht

Was haltet ihr von dieser Idee und hätten noch einige leute Lust sowas umzusetzen?
Bin schon auf eure Antworten gespannt

Ich hab ein paar Gedanken zu Papier gebracht. Entschuldigt bitte meine Sauklaue...

R ist Initial Risk. Ja ist so gemeint.

Den Verlauf der Stopp- und Zielorders dokumentiere ich erst seit letzten Monat. Die Daten dienen mir bisher weniger der Auswertung eher zur Selbstkontrolle. Ob sich das Vermerken lohnt, muss sich erst noch zeigen.

R ist Initial Risk, oder?

Das man den Verlauf der Stop- und Ziel-Order dokumentiert, ist eine gute Idee. Wertest du das auch irgendwie aus?

Hallo CT Gemeinde,

als ich diesen Thread auf der Startseite entdeckt habe, war ich sehr erfreut, denn ich dachte, mir ein paar Tricks und Kniffe zur Tradeauswertung abschauen zu können. Nach GOSOs Beitrag zu seiner künfigen Enthaltung gings leider nicht mehr richtig vorran. Deshalb möchte ich jetzt mein bisheriges Tradingjournal mit Tradedokumentation und -auswertung vorzustellen, sozusagen um den Stein wieder ins Rollen zu bringen.

Die Excelldatei besteht hauptsächlich aus 3 Teilen (Tabellenblättern)
1. Tradedokumentation (siehe Bild)

In den Spalten L bis P trage ich nur Einstiegs-, Stopp- und Zielkurs / Anzahl und ggf. Kaufdatum der Ganzen Position / Verkaufdatum 1. Teilposition / Verkauf der Restposition ein. Das CRV und das Ausstiegslevel der 1.Teilposition wird per Formel errechnet, so sehe ich sofort, ob es sich überhapt lohnt. Für Status,Timeframe, Einstiegsgrund und Pro&Contra habe ich in den jeweiligen Zellen Listen hinterlegt (weil diese Fakten immerwieder vorkommen).

Von Spalte Q bis W ist eine Bildschirmfoto mit dem jeweiligen Datum bei Entdecken des Charts

Spalte X bis AB dient für mich zur Dokumentation meiner Stoppverläufe .

Von Spalte AC bis AH ist eine Bildschirmfoto nach Tradeende oder zum Ende der Beobachtung (nach Erreichen von SL bzw. TP). Ich dokumentiere auch verworfene Einstiegssignale, um sie später noch auf geänderte Regeln des eigenen System prüfen zu können. z.B. habe ich vor 6 Monaten nur Einstiegssignale genutzt die mir ein CRV > 2 lieferten. Nach einer Auswertung der angefallenen Daten musste ich feststellen, dass die Einstiege ab einem CRV von 1,4 einen deutlich höheren Ertrag brachten.

2. Berechnungen / Überblick

Im oberen Breich lasse ich mir nach Eingabe einiger Daten vom WHS "Piprechner" die optimale Positionsgröße errechnen. Darunter kommt eine Übersicht der laufenden Trades.

Weil bei der Tradedokumentation schnell mehrere 100 Zeilen zwischen 2 laufenden Trades liegen können, lasse ich mir die Daten von der Tradedokumentation von der "Blockform" auf 2 Zeilen umrechnen. Dafür reicht die Zeilennummer vom Trade (siehe Linde-Trade von Zeile 527)

2. Tradeauswertung

Wenn ein Trade beendet ist kopiere ich die jeweilige Zeile zum Trade aus dem Tabellenblatt Berechnungen zum Tabellenblatt Tradeauswertung.
Im oberen Teil werden dann ein paar Kennziffern zu den vergangenen Trade angezeigt. Die Berechnungen erfolgen über viele Umwege in Form von Hilfsspalten. Hier muss ich immer per Hand die Formeln kopieren und das ist lässtig. Zum weiteren Automatisieren reicht leider mein Excellwissen noch nicht.


So jetzt hab ich euch ein Beispiel gezeigt. Über Kritik und Verbesserungsvorschläge würde ich mich sehr freuen. Bei Bedarf kann ich auch eine bereintige Form meiner Excelldatei zur Verfügung stellen.

Natürlich braucht nur Einer die Datenbank zu entwerfen. Mit solchen Tools kann man die Struktur und die wechselseitigen Verknüpfungen grafisch aufziehen und die Tools erzeugen die SQL-Statements zum Anlegen der Datenbank automatisch. Ab etwa 10 Tabellen wird der manuelle Entwurf schnell sehr unübersichtlich.

Wenn nur eine Handvoll Tabellen benutzt wird, geht es auch mit manuell hingeschriebenem SQL ohne jedes Zusatz-Tool.

Bei größeren Datenbanken mit einigen Hundert oder Tausend Tabellen (die wir hier nicht brauchen) werden die Bilder so groß, daß man damit trotz aller Möglichkeiten der GUI-Tools, sich Ausschnitte anzusehen, in vielen Firmen die Bilder trotzdem auf Einzelseiten gestückelt ausdruckt und dann zu riesigen Plänen zusammenklebt, mit denen man sehr imposant Wände tapezieren kann. Das ist nicht nur optische Angeberei, sondern vor diesem Hintergrund finden auch die meisten Datenbank-bezogenen Diskussionen statt.

Schade, schon wieder eingeschlafen...

Bezug nehmen auf PTs Vorschlag, ein Datenbank-Entwurfs-Tool zu verwenden, hätte ich eine Frage an die Profis. Brauch man das den? Reicht es nicht aus das ein fertiges DatenbankKonstrukt erstellt wird und hier auf dieser Seite in einem Zip-Archiv abgelegt wird? Der User entpackt es, kopiert die Daten an den vorbestimmten Ort und gut ist. Denke mal, dass wirkt ziemlich abschreckend, wenn sich jemand noch in die Bedienung eines externen Tools einarbeiten müsste.

PT: mir persönlich ist es wirklich egal, welches Produkt zum Einsatz kommt, von mir aus auch bloss Text-files (tuts wahrscheinlich auch). Das einzige was für mich nicht interessant ist, sind Lösungen für die man eine Server-Infrastruktur installieren und konfigurieren muss. Aber ich will niemanden aufhalten.

P.S.: Schade das Google-Wave noch nicht öffentlich zugänglich ist. Für ein Gemeinschafts-Projekt wäre das sicher sinnvoller als ein Forum-Thread.

Quoted from "Krümel"

Ich werde übers Wochenende mal ne Liste erstellen mit allen Performance-Kennzahlen plus -darstellung und -berechnung, die mir (und Google) so einfällt, dann könnt Ihr das ab Montag gerne ergänzen.

Mir ist leider am WE was dazwischen gekommen und ich bin noch nicht fertig mit der Auflistung und der Ausarbeitung. Ist doch mengenmäßig ganz schön viel. Wird noch 2-3 Tage dauern.

@ Purri

Also in meinem SQLite sind weder Brackets als Namens-Begrenzer noch C++-Kommentare erlaubt und SQL-Standard sind sie ohnehin nicht.

Ansonsten möchte ich zu MySQL bemerken, daß man da die Workbench gleich gratis mitbekommt, währenddessen es bei SQLite mit Entwurfs-Tools eher schlecht aussieht, wenn man nicht vorraussetzt, daß jeder gleich ein Datenbank-Entwurfs-Tool bei der Hand hat. Erfahrungsgemäß nehmen die Tabellen im Laufe der Zeit auch um viele kleine Hilfs-und Verknüpfungs-Tabellen zu, so daß es meist nicht bei den wenigen Grund-Tabellen vom Anfang bleibt.

Für den physischen Umgang mit einer SQLite-Datenbank außerhalb des Regelbetriebes mit der Applikation bietet sich das Firefox-Plugin SQLite-Manager an.

@ remon

MS Access kann eigentlich nicht als vernünftige Datenbank betrachtet werden, spielt aber in etwa in der gleichen Liga wie SQLite und ist in Form des MDB-Treibers in jedem Windows-System zumindest ohne die GUI-Oberfläche auch ohne jede Installation vorhanden. Das Vorhandensein würde aber auch auf die Desktop-Version des ausgereiften MS-SQL-Servers zutreffen.

Rein theoretisch sollte jede SQL-Datenbank eine ausreichend ähnliche Teilmenge von SQL verstehen, was leider nicht der Fall ist, da die Dialekte meist so stark voneinander abweichen, daß die Anmutung der verschiedenen Systeme ziemlich verschieden ist.

Die entscheidenden Unterschiede zeigen sich meistens bei den Programmier-Möglichkeiten auf der Ebene der SQL-Erweiterungs-Sprache bei Triggern, Stored Procedures etc. und bei der Stabilität unter Multi-User-Hochlast und Replikation, die bei Einzelplatz-Installationen für die Einbettung in eine einzige Anwendung nicht sehr zu Tragen kommen, im Multi-User-Betrieb, wie z. B. bei einer Web-Lösung aber den essentiellen Unterschied und die KO-Kriterien bedeuten.

Wegen der fast überall bei den Webhostern vorhandenen MySQL-Möglichkeit, würde ich nicht vorzeitig auf SQLite setzen, was dann eher in Richtung Einzelplatz-Lösung geht, obwohl auch einige Webhoster das SQLite-Modul für PHP anbieten.