INVESTOX-Forum

Das stellt tatsächlich ein Problem dar.

Hatte ich neulich auch mal wieder als ich eine Serie an Futures runterladen wollte am Stück.
Bleiben wir beim obigen Beispiel FDAX, da gibt´s bei TAIPAN ab 2002/06 jeden Einzelkontrakt.
Wenn man alle auf einmal laden will, muss man den Startzeitpunkt für den Backfill also auf ein Datum setzen, so dass der 1. Tick vom ältesten Kontrakt mitkommt.
Da die Tick-Historien bei L&P erst ab dem 15.5.02 (??) beginnen kann man das Datum benutzen.

Der 1. Kontrakt wird vom 15.5.02 bis 21.6.02 geladen und dann jeder einzelne Tag bis heute Tickweise durchgenudelt, was halbe Ewigkeit braucht.
Bei den weiteren Kontrakten entsteht nun ein 2 stufiges Problem:
Am Anfang wird ein Zeitraum abgefragt, der keine Daten enthält, was nutzlose Zeit benötigt und nach dem letzten Tick erneut.

Das Vorlaufproblem wird man wohl nicht automatisch lösen können.
Beim jahrelangen "leernudeln" von Daten nach dem Ende des Kontraktes wäre aber evtl. Verfahren denkbar, dass der Backfill auf dem Kontrakt optional beendet wird, wenn X Tage (im Setup von RTT einstellbar) kein einziger Tick ladbar war.

Wenn man beides lösen möchte, bleibt der Verbesserungsvorschlag an Herrn Knöpfel man müsste in jedem Titel erfassen können von wann bis wann die Daten geladen werden sollen, statt wie bisher nur ein globales Startdatum für alle Backfilltitel.

Ich habe bei Lenz & Partner gerade den Verbesserungsvorschlag eingereicht, dass Sie Ihre API erweitern sollen, dass man zu einem gegebenen Kontrakt das Datum des 1. und letzten Ticks abfragen kann.

Man war nicht völlig abgeneigt, weil ja durchaus sehr viele "sinnlose" Server belastende Abfragen durch das aktuell notwendige RTT vorgehen bei Ihnen entstehen können.
Wenn also L&P das umsetzt, könnte Herr Knöpfel eine Option in RTT einbauen für den Backfill, die da heißt: komplette Historie laden (alle Titel oder markierten Titel, so wie bisher auch).
Da mit dieser neuen API-Funktion jeweils der 1. und letzte Zeitstempel ermittelt werden kann, würde der Download sich via RTT auch nur noch auf diesen Zeitraum beschränken.

Das wär schöööööööööööön.

Herr Knöpfel,
wenn Sie das auch als sinnvolle Erweiterung ansehen und deren Umsetzung in näherer Zukunft erwägen, wäre es bestimmt hilfreich, wenn Sie als Toolanbieter auch mal bei L&P zu dem Thema nachfragen würden.

Fände ich ebenfalls sinnvoll! Ich nutze RTT/TP gerne dazu, für Backtests zu sponatenen Handels-Ideen Ideen die nötigen Daten grossflächig bei L&P runterzuziehen. Der Vorschlag würde allen nutzen, Daten schneller da und L&P Server entlastet (was nochmal allen nutzt)!

@Jupp,

Du kannst natürlich auch den "justierten FDAX" von L&P laden! Dann hat man die Historie in einem Stück und muss nicht die Quartals-Kontrakte extra laden.
Falls an der API geschraubt wird wäre ich noch für einen Real-Push-Stream "no RTT" sehr dankbar! Insbesondere natürlich für für die Scanns...

@Bernd

Der Stream kann vorkomprimiert laden-dauert nur einen Bruchteil. Wenn man das ganze noch bei Bedarf in der RTT-Datenbank ablegen könnte wäre es (für mich) schon weitestgehend perfekt!

Hallo Udo

Zitat von »Udo«

Der Stream kann vorkomprimiert laden-dauert nur einen Bruchteil

Ich weiss.

Das kommt für mich nicht in Frage. Das 10te Mal will ich während der Entwicklung doch noch auf eine tiefere Komp runter, Tick-Analyse verwenden, im Simulator Tick-by-Tick durchsteppen usw. Dann fang ich wieder vorne an und lade Daten runter, tausche Titel im / in den HSen aus - gehen sie nicht über Los, ziehen sie keine 4000 ein. Nein danke, so kann ich nicht arbeiten.

Ich hole immer die volle Ladung RTT Ticks ... die Belastung bei L&P ist ja nicht mein Problem, dann muss es halt ne Nacht lang nudeln wenn die nix Schlaues anbieten wie von Lenzelott beschrieben. Auf meiner Seite einzig ärgerlich, dass es initial solange dauert und ICH warten und entsprechend vorplanen muss.

Komprimiert wird im HS oder via Kombi, allenfalls mit nem BT. Basta

Zitat von »Udo«

Du kannst natürlich auch den "justierten FDAX" von L&P laden!

Das hat sich bei mir wenig bewährt. Besonders bei diversen Ami Futures hauen die vor-justierten Tiel aber öfter von sowas von daneben, weil die Datenanbieter halt ihre Stichtage haben zum Kontrakt umhängen. Das sind aber nicht die Tage, zu denen ICH umgehängt haben würde.

Das macht zwar viel mehr Arbeit, wenn man
* die Kontrakte einzeln durchcheckt
* den passenden Termin findet, wan man selbst im Realbetrieb geswitched hätte
* da dann selber nen Kombi draus macht und das Umhängen auch Investox nicht automatisch machen lässt sondern gemäss der eigenen Analyse!

Dafür bringt es bei weitem realistischere Ergebnisse!

Zitat von »Udo«

Du kannst natürlich auch den "justierten FDAX" von L&P laden!

Na dann schildere ich mal, welches Zusatzproblem man hat, wenn man den adjustierten Endloskontrakt per Tick benutzt:

L&P adjustiert % beim Rollover am abend vor dem Verfall (also 3. Donnerstag). Das ist soweit kein Problem und deckt sich auch meist mit der Liquidität in den Futures).

1. Fallstrick:L&P rundet nicht beim adjustieren auf die Tickgröße. Also bekommt man dann Daten wie 6978,4257 .
Dabei kann es dann halt vorkommen, dass im Backtest ein Stop oder Gewinnziel getroffen wurde, was real nicht passiert wäre, wegen minimumpricechange oder man sogar evtl. Handelssignale bekommt, die man real nicht gehabt hätte.

2. Fallstrick:
Man hat sich mühsam die knapp 100 Mio Ticks runtergeladen und zeichnet die weiteren Ticks auf.
Wenn man nun glaubt zukünftig einen adjustierten Kontrakt für den Backtest zu haben, Fehlanzeige!
Beim nächsten Rollovertermin passiert gar nix in den Tickhistorien diesbezüglich.
Man hat also den Rollovergap "sauber" in dem Titel.
Gibt zwei Auswege aus der Situation:
a) nach jedem Rollovertermin muss man komplette Historie neu laden (vorher bei L&P anfragen ob die Tickhistorie bereits adjustiert wurde!!)
b) man rechnet sich jedesmal den Rolloverfaktor von Hand aus und passt mittels Dateninspektor die historischen Kurse an.

Beide Versionen sind wohl nicht so der letzte Schrei würde ich sagen und lösen nicht den 1. Fallstrick.

Den kann man in Investox sehr einfach lösen, in dem man die Einzeltitel lädt und einen Kombititel daraus adjustiert in dem gerundet wird.
Nie wieder gebastelt ist die Folge.

Hallo Kalli,

die Fallstricke sind bekannt! Allerdings ist es nicht für jede Entwicklungsrichtung ein Fallstrick. Wenn man beispielsweise Pattern-Systeme oder Systeme auf Basis kurzer Historien entwickelt,ist es m.A.eine Option!Man sollte das Signal natürlich nicht nicht über den Verfallstag "rollen" sonst bekommt man Probleme!Persönlich setze ich keine besonderen Adjust-Methoden ein, sondern verwende die für eine Vielzahl der Strategien die primären Vorgaben! Aber wie gesagt: Das hängt das von der jeweiligen Strategie ab und ist individuell!

@Bernd
Es ging in erster Line um den FDAX.Darauf bezieht sich auch mein Vorschlag. Die Adjust-Methode von L&P ist nicht überall und uneingeschränkt verwendbar. Aber es ist neben vielen und für einige Werte eine (weitere)Option die eventuell weiter helfen könnte.Wenn man einen Scann durchführen will-was ich des öfteren tue ist es so oder so aufwendig Ticks über RTT laden und speichern zu müssen und dann zu scannen. Meine Scanns haben hohe Fluktation und ich müsste ständig neue Titel laden!

Zitat von »Udo«

Man sollte das Signal natürlich nicht nicht über den Verfallstag "rollen" sonst bekommt man Probleme!

Hallo Udo,

nicht nur damit bekommt man Probleme.
Auch wenn man zb. die berüchtigte ATR Funktion auf dailybars anwendet erhält man durch den Rollovergap für viele perioden verfälschte Signale / Filter / Stops.

Hallo Kalli,

tendernde Indikatoren-sprich jene die Bezug auf REF xy unmittelbar am Rollover-Termin nehmen, können durchaus Probleme bereiten-mal abgesehen vom Sonderfall ATR! Ich dachte eher an folgendes: Man handelt z.B. ein Kerzensignal oder ein anderes Kurz-Perioden Pattern das nicht tief bzw. keinen "bedeutenden" Rückgriff auf REF xy Perioden nimmt und auch sonst keinen Bezug darauf nimmt. Das Gap schaltet man,insbesondere im Backtest aus!Bei sehr langen Historien die mit gewissen Pattern getestet werden, und eine beträchtliche Anzahl an Signalen generieren(z.B bei sehr kurzen Engagements) sind die 4 Termine-ich möchte nicht gerade sagen egal aber die 4 möglichen Fehltrades verblassen bezogen auf die Summe wenn das Target nicht exorbitant und begrenzt ist.Dennoch sollte man nicht ganz so schludrig und mit dem "Good Luck"-Prinzip arbeiten. Daher sollte man die Terminierung auch so weit wie möglich eliminieren.Bei kleinen Komprimierungen,z.B. Tick,1,5,10 Minuten Intraday-Systemen, die nicht das und im Bereich des Rollover-Gap handeln ist es relativ egal, und darauf spielte ich an!

Zusätzlich hat man das Problem bei Feiertagen, die ebenfalls ein erhebliches Gap produzieren können!Arbeitet man mit GDs ect. sind im näheren Bereich der Termine ebenfalls verfälschte Werte tendernder Indikatoren zu erwarten,sobald sie unmittelbar über den Feiertag geschleift werden! Dazu gehören insbesondere deutsche Feiertage wie: Weihnachten-Neujahr-Ostern und Pfingsten. Entwickelt man beispielsweise mit Backprop (NN und N+) ist es ratsam, die Zeitreihe sauber zu "adjustieren" bzw. eine durch den Datenanbieter bereitgestellte (korrekt)adj. Zeitreihe zu verwenden.Meiner Erfahrung muss man das aber nicht zwangsläufig um handelbare Systeme zu entwickeln!Im EOD Chart geht Rollover,je nach Strategie ohnehin mehr oder weniger unter,genauso wie die Feiertage! Ich habe vor einiger Zeit begonnen,sehr kurze Zeitreihen für die Entwicklung heranzuziehen. Leider geht der Gedanke nicht mir jeder Strategie auf,aber mit den meisten die ich teste!Was Du und Bernd beschreibst ist ein anderer Level und da muss man sagen: Was (noch)nicht geht,geht nicht! Ich kann mir durchaus vorstellen, das es im beschriebenen Zusammenhang suboptimal ist!Aber wie geschrieben unterschieden sich beide angesprochenen Optionen in den genannten Kernpunkten und deren Auslegung!

und genau weil es soooooooo viele Fallstricke gibt adjustiere ich mir die Daten lieber selber und es wäre durchaus hilfreich für den Download der entsprechenden Kontrakte, wenn eine entsprechende Erweiterung vorhanden wäre.

Hallo,

da lässt sich vielleicht etwas machen, indem wir einen 240-Minuten-Chart abfragen und damit feststellen, wo die Historie beginnt und endet.

Viele Grüße
Andreas Knöpfel

Hallo Herr Knöpfel,

das ist ne Super Idee, müsste man nicht auf API Erweiterung von L&P warten dafür.

Allerdings kann ich mich noch dunkel daran erinnern dass nicht auf allen Zeitebenen die gleiche Historienlänge zur Verfügung steht bei Taipan Realtime, nicht dass dies bei dem Vorgehen zur Fehlerquelle wird.

Hallo,

in dieser Version ist die Option "Gesamte Historie" auf diese Weise eingebaut:

www.download.investox.de/RTT_TPRT.zip

Viele Grüße
Andreas Knöpfel

Ich teste die Funktion gerade.
Bisher muss ich sagen scheint´s wie versprochen zu funktionieren.






Das bringt immense Zeitersparnis beim Downloaden.

Hallo Herr Knöpfel, habe gerade einen Fehler gefunden.

Bei einem aktuellen Kontrakt (DAX 06/2011) wurde anscheinend der Anfang nicht erkannt:


Der Vorgängerkontrakt 03/2011 funktionier einwandfrei:


Edit Fehler tritt sporadisch bei anderen Kontrakten auf:

Hallo Herr Knöpfel,

die erweiterete Anzeige für RTT gefällt mir sehr gut. Man sieht direkt wieviele Tick´s pro Sekunde eintrudeln.


Allerdings habe ich das Gefühl, dass sich die Berechnung für die Anzahl der aktivierteten Titel ein wenig verstolpert.

Hallo herr Knöpfel,

im Falle des YG 2010/08 scheint der Fehler klar zu sein:
L&P hat einfach keine Daten zu dem Kontrakt gespeichert, anscheinend führt dies zu dem oben beschriebenen Fehler.

Im Falle des Dax Futures kann ich mir aktuell keinen Reim darauf machen, da hier Daten vorhanden sind im 240Minuten Chart wenn man in Taipan Realtime nachschaut.