INVESTOX-Forum

Hallo zusammen

Wie viele hier vor mir bin ich mit der HS Entwicklung an einem Punkt angelangt, bei dem man möglichst umfangreiche Daten Historien benötigt. Um die eigenen Entwicklungen zu Backtesten.

Auch habe ich einige Threads im Forum gefunden, aber hier hat mir das gefehlt und dort jenes.

Darum stelle ich mal vor, welche Möglichkeit ich bisher gefunden habe zum Thema Daten konvertieren. Es schliessen sich danach meine offenen Punkte an, sowie die Frage, wie andere genau vorgehen. Vielleicht hilft es jemandem hier, oder ich selbst erhalte Hinweise, wie es leichter geht oder ich die ungelösten Probleme gebacken bekomme.

Ausgangslage:
* mein Eindruck bisher ist, dass das RTT Datenformat recht performant und platz-sparend arbeitet
* also möchte ich gerne irgendwelche Daten so aufbereiten, dass sie in RTT importiert werden können und anschliessend dauerhaft im
RTT Format zur Verfügung stehen
* würde ich die Daten Konvertierung je auf eine andere Weise für eine andere Software benötigen, so soll meine Arbeit bequem anpassbar wiederverwendbar sein
* die Quell-Daten sollen irgendeinem Anbieter entstammen, Hauptsache er liefert irgendwas textmässig lesbares als kleinstem gemeinsamen Nenner (ASCII, ANSI, CSV bla bla usw. usf.)
* die Daten sollen irgendeiner Zeitzone entstammen können (Moskau, New York, Singapur, egal)
* es sollen viele Dateien, ja Gigabyte-Weise, "in einem Rutsch" konvertiert werden, damit ich diese zeitaufwändige Aktion am Abend starten und das Resultat am nächsten Tag weiter verwenden kann
* die einzelnen Dateien sollen auf der Quell- wie auf der Zielseite beliebig gross sein können, nur beschränkt durch die Kapazität meiner Fest-Platten (und diese Grenze wird von der Industrie ja jeden Tag erweitert). Meine Methode soll beliebig damit Schritt halten!
* trotzdem wollte ich nicht meinen Doktor an dieser Aufgabe machen, kein riessen Programmpaket etwickeln

Um diese Aufgabe zu lösen, habe ich mich für ein sehr altes Konzept entschieden. Es stammt sogar aus den Anfängen der C-Urväter und der Unix Umwelt. Das Träger-Programm hat keinerlei Windows Oberfläche, dafür ist es klein, smart, und steht sogar kostenlos für Windoof Umgebungen zur Verfügung: es ist awk.

Wie kann es uns heute noch nützlich sein? Nun, es schafft alle Aufgaben sogar einfach und transparent, wie ich später zeigen werde. Alles was ich davor mit Excel & Co. versucht habe ist kläglich gescheitert an einer der Anforderungen (wie etwa "beliebig gross" ). Und alles war aufwändige manuelle Arbeit für jedes einzelne File. Das muss nicht sein!

Wie es geht, werde ich in Kürze hier posten, mit Schrit für Schritt Anleitung. Auch die Einschränkungen werde ich im einzelnen erwähnen, für die ich noch keine Lösung habe: vielleicht weiss ja jemand anders hier, wie man das dann machen könne.

Bis demnächst also.


Edit: wie immer, Typo

? Frage nicht verstanden

Ich wollte z.B. die Tenfore Historien kaufen für meine weiteren Tests - aber die haben keine RTT Daten. Aber Text-Formate. Billig wäre es auch nicht und vorher muss man es sowieso anpassen für RTT. Oder man wartet, bis Knöpfel Software eine RTT Anpassung vornimmt und es selbst anbietet. Lange wurde es mir versprochen, kommt aber nix.

Natürlich gibt es auch andere Daten / Tickdaten - aber anpassen muss man es am Ende doch. S&P eMini Tickdaten und andere Werte aus US z.B., wo kann ich das preiswert "mieten" passend für Investox? Woher bekomme ich APAC Werte? Ohne es in Investox als ASCII anschliessend langsam verarbeiten zu müssen und erst noch in der falschen Zeitzone? Rechner und Daten auf UTC, ja das wär mal ein Standard. Ist leider nicht in Sicht.

Also; was kannst Du mir raten, wie macht man's? Ich nehme gerne Hilfe an, spare Zeit.

Hallo Udo

> Für ein 1-5 Minuten FDAX System sollte eine Historie von 3-6 Monaten dicke genügen.
Das hängt sicher auch mit der persönlichen Erfahrung zusammen. Deine reicht da sicher "Out-of-Sample" noch weiter zurück, so dass Du diese Aussage für Dich machen kannst.

Mir stehen keine solche Erfahrungen zur Verfügung, auch sagen andere HS-Entwickler, mit denen ich gesprochen habe, dass man längere Historien benötigt. Zumal die letzten 6 Monate Euphorie (ausser den letzten Tagen) möglicherweise nicht representativ sind für alle möglichen Börsen-Phasen?

Wie auch immer, ich handle keine europäischen Werte (man kann an meinen Postings im Forum sehen, dass TZ=CET nicht zu meinen Wach-Phasen
passt =) ) . USA oder APAC (Hongkong, Singapur, Tokyo) passt mir besser, solage ich in Europa lebe. Finde ich für diese Zonen bei L&P Tickdaten (unkomprimiert) über 10 bis 12 Jahre? Wenn nicht, wie machen andere das mit dem Datenbezug und anschliessend der Datenkonversion für Investox?

Wenn niemand eine Antwort hat, werde ich dieser Tage meine Lösung posten. In der Hoffnung auf eine rege Diskussion, was man noch besser machen könnte: ich präsentiere ja nicht den Königsweg, aber ich bin sicher, dass es ein guter Ansatz ist. Technisch gesehen. Was die Umsetzung in der Handels-Praxis angeht, bitte kommentieren. Nur so kann ich auch meine "schwächere Seite", die automatische Trading-Praxis verbessern :] Das war auch wie immer die Idee dieses Threads: ich gebe was und bekomme was. Desswegen vielen Dank für Deinen Input !!!

Hallo Udo

Zitat

Original von Udo
Ich möchte aber keine Grundsatzdiskussion zu Entwicklerstrategien in Deinem Thread lostreten und jeder Entwickler hat sein eigenes (bewährtes) Schema.

Das finde ich jetzt gar nicht schlimm, sondern wünschenswert. Es ist ja sachlich am Thema, und ich bin da sehr dankbar für! Ich habe noch gar nicht "mein Schema" gefunden, muss also Sachen ausprobieren. Sehr hilfreich sind solche Beobachtungen wie von Dir gepostet; probieren werde ich zwar trotzdem, was ich mir in den Kopf gesetzt habe - komme ich aber zu ähnlichen Schlussfolgerungen, dann kann ich den Versuch schneller abbrechen und schneller neue Ideen/Vorgehensweisen anpacken.

Hallo Juri

dieser Low Spike sieht wirklich nicht gut aus. Möglicherweise bekommt man das, wie Udo schreibt, gefixt durch ein Mail an den Datenanbieter. Oder man korrigiert es selbst - für den Backtest. Wie geht man damit um, wenn so ein Signal life hereinkommt, verhindert offensichtlich unsinnige Signale?

So, hier die versprochene Anleitung, wie man Daten von einem (ASCII, CSV) Format in ein anderes bringt.

1) Natürlich gibt es beliebig viele Möglichkeiten mit fast beliebigen Programmiersprachen; für die Lösung in diesem Beispiel
benutzen wird gawk. Ich habe awk gewählt, weil es genau für Datenkonversionen konzipiert wurde. Man kann es für Windows z.B. hier herunter laden: http://www.klabaster.com/freeware.htm . Bitte darauf achten, dort wirklich gawk zu ziehen, nicht z.B. mawk; nur gawk hat die timestamp Versionen, die wir brauchen, im Bauch.

2) gawk.zip entpachen wir in ein beliebiges Verzeichnis, bei mir z.B. C:\apps\gawk

3) Nun gehen wir (Windows XP) in die Windows Systemsteuerung, wählen auf der linken Seite "Klassische Ansicht", gehen nach System / Erweitert (unter Vista: Erweiterte Systemeinstellungen) und drücken den Button "Umgebunsgvariablen". Dort fügen wir (als Benutzervariable) entweder die Variable Path hinzu mit dem Wert aus 2), also z.B. C:\apps\gawk , oder falls Path bereits existiert, hängen wir dem vorhandenen Wert dies an: ;C:\apps\gawk (das Simikolon ist wichtig beim anhängen).

4) Das Fenster nun mit OK bestätigen, ebenso das Systemeigenschaften Fenster auch mit OK verlassen

5) nun machen wir einen kleinen Test: Windows-Taste gedrückt halten und Taste R drücken: unter öffnen geben wir cmd ein (Enter). Auf dem nun sich öffnenden Command Prompt bitte mal gawk eingeben, es sollte die Hilfe-Anzeige von gawk angezeigt werden. Wenn nur eine Fehlermeldung kommt: zurück zu 1)

6) Im Folgenden gehe ich mal davon aus, dass die zu konvertierenden Daten (ASCII Datein) im Verzeichniss c:\temp\tickkonvert abgelegt sind mit der Endung .csv

7) Bitte das als Dateianhang gepostete Coding als Datei a2rtti.awk ins Verzeichnis c:\temp\tickkonvert abspeichern (der Name des .awk Scripts ist beliebig, aber im folgenden arbeite ich mal mit diesem Namen; a2rtti soll ein Mnemonik sein für Ascii to RTT Import, .awk erinnert uns auch Monate später noch daran, dass es sich um ein awk Script handelt) (im Dateianhang musste ich den Namen a2rtti.awk.txt verwenden, weil .awk Dateien nicht erlaubt sind im Forum ?!?, also beim Abspeichern nicht vergessen, aus a2rtti.awk.txt wieder a2rtti.awk zu machen)

Mit dem Notepad (bitte keinesfalls mit Word & Co.) öffnen wir das Script a2rtti.awk und passen gemäss den Kommentaren das Coding an die eigenen zu konvertierenden Daten an

9) nun öffnen wir erneut ein Command Fenster wie unter 5) beschrieben und bewegen uns mit dem Befehl cd \temp\tickkonvert dort hin

10) Jetzt rufen wir diesen Befehl auf: gawk -f a2rtti.awk *.csv - und einige Zeit später gibt es zusätzlich zu den .csv Dateien auch .rtt.txt Dateien, die man in RTT importieren kann (Titelauswahl, neuen Titel hinzufügen. Danach Verwaltung / Daten / Importieren und den Pfad zur jeweiligen .rtt.txt Datei eingeben)

Die derzeitigen Einschränkungen (z.B. Sommer/Winterzeit Umstellung bei verschiedenen Zeitzonen) sowei mögliche Lösungsansätze sind im Script-text dokumentiert.

Was mir noch nicht klar ist: falls die Eingabedaten gerollte, aber nicht adjustierte Daten sind, wie könnte man a) eine geeignete Adjustierung im Script vorsehen oder ist es möglich/besser dies b) später in Investox zu machen? Ich habe im Forum Threads gefunden über eine mit Investox angeblich mögliche Adjustierung aber keine Details, und die Investox Hilfe hat mir keine Treffer zum Begriff Adjustierung gezeigt.

Für die Umsetzung von 24GB .csv Daten braucht mein Rechner knapp 3 Stunden (AMD X2 3800+ auf 2GHz (keine Tuning Option aktiviert, kein Übertackten für diesen Test), 2GB RAM, 500GB Platte Samsung HD501LJ).

Viel Erfolg!

Oh, wieder wach heute morgen sehe ich, es gibt noch einen Fehler im Script a2rtti.awk:

Die Zeile mit NR == 1 {
muss so heissen: FNR = 1 {

... damit die Kopfzeile auf für jedes weitere File neu erzeugt wird.

Hallo Torsten

Klar, in RTT selbst mit Export. Danach kannst Du sie mit meiner hier geposteten Scriptvorlage beliebig anpassen, um sie in eine andere Software zu importieren.


Ausserdem sehe ich bei mir einen Hang zur Legastenie (oder ist auch das wieder falsch: Legasthenie ): habe ja die Korrektur oben gepostet, nur ist die wieder nicht korrekt, man muss natürlich zwei Gelichheitszeichen schreiben, sonst ist's ja kein Vergleich sondern eine Zuweisung:

FNR == 1 {

Hallo Hans-Jürgen

Früher hätte man so ein kleines = statt == Fehlerchen schnell ausbessern können im ursprünglichen Posting. Heute, mit der neuen Policie nur noch eine Stunde ändern zu dürfen, muss man ja echt voll die Hosen runter lassen im Fehlerfall Das ist schon fast wie ein Audit-Protokoll jetzt ...

OK, kein Vorwurf, ich verstehe ja die Gründe. Aber es erscheint mir schon mühsam. Schöne neue Welt.

Hallo Torsten

Stimmt, das RTT Format arbeitet platzsparend und Investox geht damit auch sonst resourcen-schonend und performant um.

Diese ASCII- und CSV Formate sind unangenehm gross, aber dafür kann man sie mit Tools wie awk beliebig "rumschubsen". Praktisch alle Programme können ASCII Im- und exportieren. Dazwischen muss man mit einem Konvertierungs-Script wie dem von mir geposteten Beispiel machmal "vermittelnd eingreifen".

Ich verwende solche Formate nur zum Austausch zwischen Programmen, und bearbeite sie nur in NTFS komprimierten Directories. So braucht während der Konversion eine Anzahl von 80 Dateien von z.B. 143 GB bei mir auf der Platte nur 23 GB. (siehe Eigenschaften auf dem Directory und der Unterschied zwischen "Grösse" und "Grösse auf dem Datenträger" ).

Wenn ich die Dateien mit awk nach RTT (oder von RTT in eine Form für ein anderes Programm) gebracht habe, so werden sie natürlich wieder gelöscht. Allenfalls wird die Ursprungs-Datei gezipt und auf DVDs gespeichert.

Noch ein Tipp, wie man schnell das Ergebniss einer Datenkonversion mit awk und einem eigenen Script begutachten kann: am Command Prompt in's Verzeichnis wechseln mit dem Befehl cd, und dann dort mit dem Befehl more die ersten Zeilen ansehen.

Das geht um Längen schneller, als die Datei in irgendeinen Editor laden, und meist sieht man an den ersten Zeilen, ob alles so ist wie es sein soll!