INVESTOX-Forum

hi udo.
die kennzahlen sind ausserordentlich gut.
nur die student signifikanz ist niedig.
das system läuft gerade im test, ich
kann das heute abend mal posten.
heute hat es zwei signale korrekt geliefert.

die HS sind mit mit der gleichen komp eingestellt wie
die netze. die trainings- und optizeiträume sind auch
in etwa deckungsgleich. der KoZR beginnt ende september
2006. ich habe das system noch mit einem separaten netz
für long positionen versehen, damit etwas mehr trades
generiert werden und alles aus dem gleichen grund auf 15m gesetzt;
also: die komps sind gleich, die zeiträume auch (paar tage unterschied
kann ja nichts grosses ausmachen), alles läuft mit delay 1.
die kennzahlen des netzes sind 85% trefferquote im KoZR,
0.5 korrel, 0.6 t-test, 0.5 radom walk. da ich keinen vergleich
habe, weiss ich nicht, ob und wie gut das ist...

die indis sind fehlerfrei, die habe ich schon in anderen HS
ohne probleme verwendet.

hallo zusammen,

ich habe eine neue fehlerquelle bei nicht zeitbasierten systemen ausgemacht.
im falle von tick/range/renko basierten systemen hängt die bildung neuer bars
ja bekanntlich von der aktivität im markt ab.
wenn man nun die option "einstieg in letzte periode zulassen" in den testbedingungen NICHT
abhakt, führt das zu zukunftssicht, denn das system kann ja hier im gegensatz zu zeitbasierten charts
und HS zum zeitpunkt des entrys noch nicht wissen, ob die periode die letzte des tages sein wird.
das hängt von der weiteren aktivität des tages ab.
somit ist das ergebnis klar: entries werden nur berechnet, wenn weiterhin eine bewegung stattgefunden
hat, sonst verschwindet der trade am ende des tages wieder. dieser effekt ist besonders gross bei grossen
komps. also: option immer abhaken, sonst erlebt man unangenehme überraschungen.

Hallo,

Eine kurze Anmerkung:

Nachteil von Tickdaten für "realistischen" BT: Extremer/hoher Rechenaufwand.
Vorteil: Intraday Stops etc. können korrekt berechnet werden.
Nachteil von komprimierten Daten: Intraday Stops etc. können nicht korrekt berechnet werden.
Vorteil: hohe (relative) Performance.

Lösungsvorschlag: Einmalig beim Komprimieren der Tickdaten die OHLC Daten annotieren/anreichern. HL mit Zeitstempeln verstehen bzw der Info was zuerst kam.
Dann beim BTen berücksichtigen.
Damit hätte man beide Vorteile vereint.
(Klar braucht man Tickdaten, aber nur einmalig beim Konvertieren/Komprimieren)

Der Aufwand wäre mMn halbwegs überschaubar.

Sowas würd ich mir jedenfalls wünschen

mfg, upgap

Hallo,

also wenn ich das richtig verstanden habe, dann ist es nicht möglich, z.B. auf einem 15-Minuten-Chart auf Tickbasis backzutesten? Falls das stimmt, dann wäre das ziemlich beschämend für IV, denn das kann sogar der MetaTrader und der kostet nichts. Meiner bescheidenen Meinung nach sollte das "Feature" (für ein so wissenschaftlich und korrekt ausgerichtetes Tool sollte das eigentlich eine Selbverständlichkeit sein) unbedingt hinein, sonst kann man das Backtesting für kurzfristige Strategien (Scalping bei einigen Minuten bis maximal 1-2 Stunden pro Trade), wo zwar auf einer Zeitbasis im Minuten-Bereich gearbeitet wird, aber die Ein- und Ausstiege/Stops im Moment des Eintreffens der Situation sofort ausgeführt werden müssen, vergessen.

Hallo vtec,

da musst Du was falsch verstanden haben. Natürlich ist es möglich, auf Tickbasis backzutesten - wenn man denn Tickdaten für die fragliche Zeit vorliegen hat und nicht nur 15min Komprimierung und. Wenn ich Dich richtig verstehe, möchtest Du mit Regeln einsteigen, die auf einer x-Minuten Komprimierung beruhen, aber aussteigen/ausgestoppt werden, sobald ein bestimmter Kurs genau erreicht wurde, und nicht erst am Ende der fraglichen Periode. Das ist natürlich ohne weiteres möglich und zwar auch ohne auf Tickbasis heruntergehen zu müssen, etwa mit Intradaystopps. Die korrekte Programmierung dieses backtests ist allerdings mit einigen Fallstricken versehen, um die es in genau diesem thread geht.
Ein schönes Wochenende noch
Yoggi

Hi Yoggi (und natürlich auch alle Anderen ;-) ),

kann sein, dass ich mich durch manche Beiträge in diesem Thread verwirren habe lassen. Ich habe ein System, das auf Indikatoren basiert, die min. auf 15-Minuten-Candles berechnet werden sollen (darunter bekomme ich einfach zu viele Fehlsignale). Der Einstieg soll jedoch an der laufenden Candle sofort erfolgen, wenn die Einstiegsbedingung bei diesem Tick gegeben ist (z.B. wenn eben der Wert eines Indikators für die laufende Candle (sprich den letzten Preis) von mir aus größer ist als jener für die Candle davor) und nicht erst z.B. beim Close-Kurs dieser Candle. Das müsste ich doch eigentlich beim Handelssystem im Reiter "Test" für die Enter-Basis einstellen können. Ich nehme an, Close bezieht sich hier auf den Close-Kurs der fertigen aktuellen Candle. Wie schaffe ich es hier, den aktuellen Tick-Wert als Einstiegspreis zu bekommen?

Vielen Dank!

@Bernd

Du schreibst,wie man so ein System für den Handel einstellt. Meine spezielle Frage dazu ist, ob man an einer 15 Minute Kerze Tick für Tick backtesten kann, ohne auf Tickkomprimierung zu schalten oder sonstige Umwege und Schleifen programmieren muss? Selbstverständlich müssen Tickdaten vorliegen. Ein Beispiel soll meine Frage verdeutlichen! Das System soll auf 15 Minuten Komprimierung basieren. Die Daten wurden Tick für Tick gesammelt. Das System soll an einer Historie über einen längeren Zeitraum an der 15 Komprimierung getestet werden. Die Stops sollen tickgenau simuliert und abgerechnet werden. Soweit ich es sehe,kann der Intraday-Stopp lediglich 4 Levels ansteuern und taxt jenen, der "nahe" am entsprechenden Kurs Close;Open,Low,High liegt. Würde der tatsächliche Stopp 5 Ticks unter dem Abrechnungsverfahren dieses Schemas liegen,besteht die Wahrscheinlichkeit,dass die Taxe erheblich von der Realität abweicht? Davon abgesehen ist die Wahrscheinlichkeit relativ hoch, das bei einem Ticksystem für HeavyTrader Realität und tatsächliche Performance öfter klaffen. Das begründet sich meiner Meinung aus dem unwillkürlich entstehenden Timelag der Hardware,Software und Brokerverbindung. Einige Softwares sind schnell (am schnellsten die Online Handelsplattformen) und können diesen Nachteil verringern,aber nicht ganz ausschalten. Die Internetleitung und die Weiterleitung vom Broker an den Börsenhandelsplatz kann man kaum beeinflussen. Im übrigen finde ich es sehr schwach das man bei Investox nur einen einzigen Broker für den vollautomatischen Handel zur Verfügung hat,denn somit schränkt sich die Tragweite der Software erheblich ein. Was machen die CFD oder Forex Händler die nicht über Interactive Brokers handeln? Ist man quasi gezwungen ein Konto bei IB zu eröffnen, wenn der Handel automatisiert werden soll?

lando

Zitat von »Bernd«

Dein Signal würde im Life-Betrieb also wieder "zurückgenommen" - das meint man u.a. mit "in die Zukunft blicken".

Hi Bernd,

danke für die Erläuterungen. Genau das möchte ich, im Live-Betrieb funktioniert das so. Ich möchte, dass auch im Backtest in der aktuellen Periode Signale erscheinen, die auch wieder verschwinden können, das ist in Ordnung für dieses System. Es geht darum, bei Auftreten von einem gewisssen höheren Volumen u.s.w. sofort einzusteigen. Beim Close einer 15-Minuten-Candle wäre ich viel zu spät dran. Da schaue ich aber nicht in die Zukunft, ich kann auf diese Weise nur in die Vergangenheit schauen und zwar auf alle vergangenen Ticks der sich aktuell ausbildenden Candle (manifestiert im aktuellen OHLC und Volumen). Für mich ist es irrelevant, ob die letzte Periode schon fertig ist oder nicht.

Erwischt Ich wollte als eines meiner ersten Investox-Projekte vielversprechende Fremd-Indikatoren hernehmen und ein System dazu, das, genauso wie Bernd es beschrieben hat, Signale liefern, aber der Einstieg manuell erfolgen soll, wobei es da eigentlich diskretionär keinen Spielraum für den Einstieg geben sollte, was ich aber eben durch Backtesting oder Simulation herausfinden wollte, wie das System auf sich alleine gestellt so performt. Klar wird es durch einen diskretionären Anteil wahrscheinlich besser funktionieren (wobei man den für sich selbst ausmachen muss), aber ich wollte wissen, wie es (nicht ) ohne diskretionären Anteil funktioniert. Mein Problem ist daher, ich weiß nicht, was die Indikatoren genau tun und muss auf einer Zeitbasis/Komprimierung und System bleiben, wo es funktioniert. Schon klar, dass ich besser meine eigenen Systeme schreiben sollte, aber wenn es gut funzt, warum nicht umsetzen. Vielleicht bleibt mir nichts, als dieses System in einer beschleunigten Simulation händisch nachzutraden, um Erfahrungen zu sammeln.

Zitat von »vtec«

Klar wird es durch einen diskretionären Anteil wahrscheinlich besser funktionieren

Na, dann wünsche ich Dir, dass Dir Dein Selbstvertrauen noch lange erhalten bleibt ... Worauf stützt Du die Erwartung, dass ein von Dir beobachtetes System besser wird, wenn Du manchmal/öfters/immer manuell eingreifst?
Alles Gute
Yoggi

@Bernd

Eine Antwort in 2 Etappen,denn bei einigen Zeilen deiner umfangreichen Antwort gibt es für mich Erklärungsbedarf und Diskussionsstoff!
Bei der ersten Antwort,Tickkomprimierung kann man softwareseitig bestimmt einrichten, das aus einer Tickhistorie eine 15 Minuten Kerze hochkomprimiert oder eine vorkomprimierte 15 Minuten Kerze direkt geladen wird? Die meisten, sehr schnellen Software arbeiten mit vorkomprimierten Daten,können aber dennoch im Backtest mit Ticks umgehen,wenn einmalig eine Tickhistorie vorliegt! Aber darauf wollte ich eigentlich nicht hinaus.Mir ist wichtig, das bei einer 15 Minuten Kerze der Stopp im Backtest relativ nah an der Realität liegt und das ist mit dem Intraday Stopp nicht unbedingt der Fall. Das der Tick im realen Handel exakt abgerechnet wird betrachte ich für den Anspruch der Software als selbstverständlich! Ich möchte mir als Anwender aber auch nicht die Finger an der Tastatur wundklopfen und das Hirn mit Mathematik zermartern, sondern Funktionen die man als Trader als selbstverständlich betrachtet und im täglichen Gebrauch als Entwickler und Trader immer wieder nutzt ansatzweise vorbereitet und einfach zugänglich findet. Mir sind beim lesen der zahlreichen Postings einige haarsträubende Sachen aufgefallen die zwangsläufig den Eindruck erwecken, das die Software extrem verschachtelt aufgebaut ist und viele Sachen nur dem versierten Anwender zugänglich sind.Das möchtee ich im anderen Teil näher ansprechen und habe auch Fragen dazu!

Eine Intraday Kerze,im vorliegenden Fall auf 15 Minuten komprimiert kann problemlos 50 Ticks Handelsspanne umfassen. Wenn das Close,Open,High,Low weit auseinander liegen kann es zu erheblichen Abweichungen kommen wenn der next Neighbor Level abgerechnet wird! Das mag alles schön und gut sein wenn ein System pro Tag ein paar mal handelt aber wenn 50-100 mal gehandelt werden soll und auf dem Tick 5-20 Kontrakte eingesetzt werden, ist die Abrechnung und der Backtest als Leitfaden zum Teufel! Das Danebenliegen summiert sich, geometrisch ausgedrückt im Quadrat. Mir ist vollkommen klar,das man einen Test niemals hundert Prozent real umsetzen kann aber mit jeder Ungenauigkeit die man im System programmiert oder hinnehmen muss wenn eine Software verschieden Funktionen fehlen oder zäh und träge verarbeitet werden (allgemeiner Bezug), entfernt sich die Trefferquote des Backtests immer weiter von der Realität.Dann kann man den Backtest über den Daumen peilen. Wir machen Backtests um die wahrscheinlichste Performance für zukünftige Trades zu ermitteln und den Handel zu optimieren. Wenn alles Kopf steht ist der Backtest nur ein Statist! Ich komprimiere Daten deshalb,da ich in unterschiedlichen Segmenten mit meinen gewählten Komprimierungen gut zurecht komme und subjektiv betrachtet viele unbedeutende Oszillationen aus der Datenreihen gefiltert werden. Hinsichtlich der Slippage kann man bei der beschriebenen herangehenweise sollte man nicht davon ausgehen das man xbeliebige oder die wahrscheinlichste Zahl einsetzt und alles wird gut. Das funktioniert unter Vorbehalt wenn es um kleine Summen geht aber nicht bei hoher Kontraktanzahl gepaart mit hoher Handelsfrequenz! Die Abweichung summiert sich im Quadrat! Eine Slippage entsteht durch den Spread wenn man nicht mit Bid und Ask Kursen arbeitet oder bei Verzögerungen beim Transfair.Fehlerhafte Abrechnungen im Vergleich zum Backtest begründen sich im höherfrequenten Handel manchmal durch einen ausbleibenden oder abweichenden Fill! Diese Toleranz kann man nicht planen aber beispielsweise nach einiger Zeit mit Erfahrungswerten einbeziehen. Das geht so weit in Ordnung und den Anspruch, das eine Software das voraus sieht, habe ich nicht

@Yoggi
Die Frage ist zwar nicht an mich gerichtet, aber es ist möglich erfolgreich in Systeme einzugreifen aber nur unter der Voraussetzung ,das man genügend Erfahrung und Routine und ein Konzept für den jeweils gehandelten Wert hat! Ein direkter Eingriff in eine laufende Handlesabfolge ist kritisch aber das System an- und abschalten,eine manuelle Handelsaktivitätensteuerung ist durchaus sinnvoll wenn man erkennt, dass das Handelssytem für das vorrangige Börsenumfeld nicht konzeptiert ist, was man als Entwickler über das eigene System eigentlich wissen sollte!

lando