* Eurex Tickdaten / Erich Florek: Fehlerquelle Datenfeed

@ Driehaus [#50]

AWK mag zum Umformatieren von "Record" basierten Datenformaten ja brauchbar sein, aber zum regelbasierten Filtern von EUREX Tickfiles braucht es doch etwas mehr Logik. Z.B. Das Erkennen einer Folge von sagen wir 20 Ticks, welche zwar innerhalb der Folge schlüssig sind, aber die Folge selbst um +/- X-Ticks merklich von den vorhergehenden und dann wieder folgenden Ticks abweicht. Ein gute Software wird diesen Bereich erkennen und zunächst nur markieren. Anschließend sollte dann manuell entscheidbar sein, ob man zukünftig dies Tickfolge ignorieren/auslassen will, oder ob die Ticks per Korrekturoffset sinnvoll "mittig" eingepasst werden sollen. "Auslassen" wäre Default, aber es gibt dynamische Systeme, welche in RT Ticks/Zeiteinheit zählen (egal ob im Nachhinein sinnvoll, denn RT wüsste man es ja noch nicht), die brauchen diese Ticks samt TimeStamp... Sowas ist schon in C++/Delphi etwas Aufwand, geht sowas in AWK?

Das Filtern in NULL/MAX Preisen/Volumen und ein relativer Trigger zum letzten Wert ist zumindest in realer Anwendung nicht ausreichend!

In der Anzeige und Darstellung brauchbare Ergebnisse lassen sich bei Datenmengen im GB Bereich zwar theoretisch über Einzelfiles mit festen Datensatzgrößen erreichen. Praktisch für Auswertungen ist aber wohl eine Datenbank mit EOD Records, welche im Datensatz jeweils zusätzlich die möglichst gut gepackten Tickdaten des Tages speichert die bessere Lösung. Ob das per NestedTable (Interbase/Oracle) oder simpel per komprimierten BLOB Feld gelöst wird, hängt dann mehr von der Zielanwendung ab. Tickdaten in "Klartext" ASCII braucht man eh nur für den Import in Standardprogrammen, nur sind diese zu 98% mit genannten Datenmengen überfordert.

Leider geht es den Menschen wie den Leuten, gute Lösungen gibt es zwar, nur leider ist das Produnkt und der Entwickler irgendwann irgendwie nicht mehr so "greifbar" wie man es sich wünscht;)

also Bitte, ich will doch kein Flugzeug entwickeln! :)

@ TimeTrade

AWK ist eine einfache Programmiersprache, in der Du jeden Alogrithmus programmieren kannst, natürlich auch komplexe.
Mir gefällt die Einfachheit und ich bin für meine Aufgabenstellungen noch nicht an Grenzen gestoßen.
Es ist natürlich keine schicke, fertige Software-Lösung mit grafischer Benutzeroberfläche usw.

"Leider geht es den Menschen wie den Leuten, gute Lösungen gibt es zwar, nur leider ist das Produnkt und der Entwickler irgendwann irgendwie nicht mehr so "greifbar" wie man es sich wünscht;)"

Richtig, deshalb mache ich den Kram auch quick and dirty selbst!

@ Driehaus [#54]

..."den Kram auch quick and dirty selbst"...

So mach ich es im Prinzip im ersten Schritt einer Lösung auch immer. Nur hab ich mich schon länger entschieden, jede meiner Lösungen in was bestehendes "einzubinden". Was nützt all das gute Zeug, wenn ich mal gegen einen Baum fahre und dann länger flach liege. Wenn man sowas noch im Kooperation macht, dann ist zumindest die Chance gut, das einmal Erreichtes auch weiter sinnvoll genutzt werden kann, wenn man selbst ausfällt. Das ist im Prinzip der Grund, warum ich lieber den umständlichen Weg kompletter und "kompatibler" Tools mit GUI bevorzuge.
Nur leider haben solche "Komplettlösungen" auch immer einen Nachteil, man kann sie nicht einfach mal so ungefragt weitergeben.