Lieber Besucher, herzlich willkommen bei: INVESTOX-Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.
Sonntag, 2. September 2007, 23:43
Hallo Bernd,
Es wäre auch wünschenswert statt 3 Stops (Verluststop, Intraday-Verlust und Sofort-Verluststop) einen einzigen Verluststop zu haben (vielleicht mit einem "Hacken" "Stop gültig auch in der aktuellen Periode")
das gilt nur für Backtest. Im Real- bzw. Papertrading funktioniert es richtig. Deswegen sollte man ein HS zuerst mit Papertrading testen. Oder mit BT auf Tickbasis. Ist natürlich blöd und doppelt gemoppelt, wenn man sowieso einen Titel mit Tickdaten hat.na das ist ja schon eine Überraschung, dass die Ticks nicht innerhalb einer Periode in der Reihenfolge zugeordnet werden können. Ich hatte das Gegenteil ehrlicherweise immer als Selbstverständlichkeit vorausgesetzt.
Es wäre auch wünschenswert statt 3 Stops (Verluststop, Intraday-Verlust und Sofort-Verluststop) einen einzigen Verluststop zu haben (vielleicht mit einem "Hacken" "Stop gültig auch in der aktuellen Periode")
Montag, 3. September 2007, 00:41
Hallo Bernd,
genauso ist es. Im Realtest kommen die Daten Tickweise und IV kann sehr wohl unterscheiden was zuerst kommt. Im Backtest schaut IV nur auf Komprimierung von deinem HS und sieht nur Open, Low, High und Close von deiner Periode, deswegen hat IV auch keine Ahnung was zuerst eintritt.
Wie Udo schon sagte:
genauso ist es. Im Realtest kommen die Daten Tickweise und IV kann sehr wohl unterscheiden was zuerst kommt. Im Backtest schaut IV nur auf Komprimierung von deinem HS und sieht nur Open, Low, High und Close von deiner Periode, deswegen hat IV auch keine Ahnung was zuerst eintritt.
Wie Udo schon sagte:
Ist halt blöd, wenn deine zugrundeliegende Daten Tickdaten sind
Zitat
Umso größer komprimiert und langanhaltender eine Periode ist (z.B. P&F Reihen) ,desto drastischer kann sich das ganze auswirken!
Montag, 3. September 2007, 01:15
Im Realtest kommen die Daten Tickweise und IV kann sehr wohl unterscheiden was zuerst kommt.
Hallo,
das gilt dann nach Udos Konstellation dann doch nicht immer. Ich meine auch, mich an einige Live-Handelsmomente erinnern zu können, bei denen ein Entersignal gemeldet wurde und innerhalb der Periode plötzlich verschwand, ich konnte es selbst im Chart verschwinden sehen. Habe aus zeitgründen dieses Phänomen damals nicht gepostet.
Damals hatte ich keinerlei Vorstellung, woran das gelegen haben könnte, zumal ich mich vorbehaltlos auf ein absolut funktionierendes Stoppmanagement im Programm verlassen habe.
Montag, 3. September 2007, 16:56
Hallo Udo & Bernd,
mir geht es darum, dass im Backtest falsch abgerechnet wird und man merkt es nicht einmal. Im Realhandel sieht man diese Flattersignale (mit BT auf Tickbasis, denke ich auch, habe noch nie ausprobiert) und merkt, dass irgendwas mit dem HS nicht stimmt.
Hallo Olli,
ich bezweifle, dass komp dir was bring. Teste dein HS mit BT.
Edit.
Ich sehe schon, hier bist du auf dem richtigen Weg
mir geht es darum, dass im Backtest falsch abgerechnet wird und man merkt es nicht einmal. Im Realhandel sieht man diese Flattersignale (mit BT auf Tickbasis, denke ich auch, habe noch nie ausprobiert) und merkt, dass irgendwas mit dem HS nicht stimmt.
Hallo Olli,
ich bezweifle, dass komp dir was bring. Teste dein HS mit BT.
Edit.
Ich sehe schon, hier bist du auf dem richtigen Weg
Montag, 3. September 2007, 17:30
Hallo zusammen,
irgend wie dreht es sich ja wohl um diese Aussage (@Juri: hab nur deinen Satz kopiert, weil er m. E. das Problem trifft):
Also ich weiß nicht ob man das so sagen kann. FALSCH ist sicherlich der falsche Ausdruck.
Führt euch mal vor Augen, was INV in einem Perioden basierten System überhaupt zur Verfügung hat. Richtig: OPEN, CLOSE, HIGH und LOW. Liegen nun Gewinn-Stopp (egal ob Intraday-/Sofort-Stopp) UND Verlust-Stopp innerhalb EINER Periode, hat INV KEINE Möglichkeit festzustellen, welcher der Stopps zuerst eintraf! Wie denn auch? Die Stopps müssen aus Sicht einer Programmlogik aber irgend wie berücksichtigt werden. Was bleibt einem Programmierer da übrig, als diese Logik festzulegen - sonst läuft das Programm nicht weiter. M. E. liegt es in der Verantwortung des HS-Entwicklers zu erkennen oder auszuschließen, dass Gewinn- UND Verlust-Stopp in einer Periode liegen.
Wenn man sich jetzt noch das Laufenlassen eines HS mit unvollendeten Perioden anschaut, muss man ja eigentlich feststellen, dass mit JEDEM Tick die Periode abgeschlossen wird!! Und damit wird nach JEDEM Tick die interne Programmlogik ablaufen, und somit ist es auch klar, dass 10 Ticks später einer andere Konstellation (O, C, H, L) vorliegen kann, was u. U. auch zur Zurücknahme von Signalen führen kann. M. E. alles sehr logisch und nicht zu ändern wenn man nur komprimierte Daten (EoD etc.) hat. Hat man Tickdaten, kann man das HS so aufbauen, dass man die Stopps an die Tick "hängt" und die Enter-/Exit-Signale über Komp() generiert. Die Komprimierung des HS ist dann TICK und die Stopps können nicht innerhalb einer Periode auftreten, da die Periode der Tick ist.
Jetzt kann man natürlich die Forderung stellen, dass INV einen Tickchart im Hintergrund abfragt, falls man Tick-Daten hat, uns somit die Stopps "richtig" abarbeitet. Ob das möglich ist, kann nur AK beantworten, auf jeden Fall bedeutete dies, dass INV dann beim Vorhandesein von Tick-Daten in einem Perioden-HS eine andere Programmlogik abarbeiten müsste. Für den Backtest brächte das aber auch nur etwas, wenn dieser ebenfalls die Tickdaten berücksichtigte. Ich vermute mal, dass dies nur aufwändig zu realisieren wäre.
irgend wie dreht es sich ja wohl um diese Aussage (@Juri: hab nur deinen Satz kopiert, weil er m. E. das Problem trifft):
dass im Backtest falsch abgerechnet wird und man merkt es nicht einmal.
Also ich weiß nicht ob man das so sagen kann. FALSCH ist sicherlich der falsche Ausdruck.
Führt euch mal vor Augen, was INV in einem Perioden basierten System überhaupt zur Verfügung hat. Richtig: OPEN, CLOSE, HIGH und LOW. Liegen nun Gewinn-Stopp (egal ob Intraday-/Sofort-Stopp) UND Verlust-Stopp innerhalb EINER Periode, hat INV KEINE Möglichkeit festzustellen, welcher der Stopps zuerst eintraf! Wie denn auch? Die Stopps müssen aus Sicht einer Programmlogik aber irgend wie berücksichtigt werden. Was bleibt einem Programmierer da übrig, als diese Logik festzulegen - sonst läuft das Programm nicht weiter. M. E. liegt es in der Verantwortung des HS-Entwicklers zu erkennen oder auszuschließen, dass Gewinn- UND Verlust-Stopp in einer Periode liegen.
Wenn man sich jetzt noch das Laufenlassen eines HS mit unvollendeten Perioden anschaut, muss man ja eigentlich feststellen, dass mit JEDEM Tick die Periode abgeschlossen wird!! Und damit wird nach JEDEM Tick die interne Programmlogik ablaufen, und somit ist es auch klar, dass 10 Ticks später einer andere Konstellation (O, C, H, L) vorliegen kann, was u. U. auch zur Zurücknahme von Signalen führen kann. M. E. alles sehr logisch und nicht zu ändern wenn man nur komprimierte Daten (EoD etc.) hat. Hat man Tickdaten, kann man das HS so aufbauen, dass man die Stopps an die Tick "hängt" und die Enter-/Exit-Signale über Komp() generiert. Die Komprimierung des HS ist dann TICK und die Stopps können nicht innerhalb einer Periode auftreten, da die Periode der Tick ist.
Jetzt kann man natürlich die Forderung stellen, dass INV einen Tickchart im Hintergrund abfragt, falls man Tick-Daten hat, uns somit die Stopps "richtig" abarbeitet. Ob das möglich ist, kann nur AK beantworten, auf jeden Fall bedeutete dies, dass INV dann beim Vorhandesein von Tick-Daten in einem Perioden-HS eine andere Programmlogik abarbeiten müsste. Für den Backtest brächte das aber auch nur etwas, wenn dieser ebenfalls die Tickdaten berücksichtigte. Ich vermute mal, dass dies nur aufwändig zu realisieren wäre.
Viele Grüße,
Hans-Jürgen
Hans-Jürgen
Montag, 3. September 2007, 20:24
Hallo Hans-Jürgen,
ich kann nur Anke zustimmen.
Insbesonders zu deinem letzten Punkt
ich kann nur Anke zustimmen.
Insbesonders zu deinem letzten Punkt
Jeder sammelt sowieso die Tickdaten und es wäre sehr schön wenn IV diese Daten für "richtige" Backtests auch benutzt.
Jetzt kann man natürlich die Forderung stellen, dass INV einen Tickchart im Hintergrund abfragt, falls man Tick-Daten hat, uns somit die Stopps "richtig" abarbeitet. Ob das möglich ist, kann nur AK beantworten, auf jeden Fall bedeutete dies, dass INV dann beim Vorhandesein von Tick-Daten in einem Perioden-HS eine andere Programmlogik abarbeiten müsste. Für den Backtest brächte das aber auch nur etwas, wenn dieser ebenfalls die Tickdaten berücksichtigte. Ich vermute mal, dass dies nur aufwändig zu realisieren wäre.