INVESTOX-Forum

Hallo,

der Vorschlag hat zweifelsohne Charme,aber wie soll man das System backtesten, wenn sich die Brickgröße aufgrund von Size-Steuerungsparametern des öfteren ändert? Mit der Änderung der Brickgröße ändert sich die komplette Zeitreihe und ältere Backtestergebnisse werden "überschrieben"! Man könnte das im besten Fall via Simulation testen und das kann bei langen Zeitreihen nerven-und zeitaufreibend sein!Insofern wäre eine Master-Slave Lösung bis dato eine anwendbare Möglichkeit.Beim halbautomatischen Direkthandel (ohne Backtest) könnte der Vorschlag m.A. sofort zum Einsatz kommen wenn man keinen Wert auf (visuellen)Reserach der gehandelten Signal-Ergebnisse legt!

Hallo Yoggi,

das Problem ist, das die geöffnete Zeitreihe ein Ganzes darstellt, auch wenn die Neuberechnung der Bricks jeden Handelstag neu berechnet wird.
Beispiel: Heute wird die Brickgröße 5 (oder alternativ 0,5%) berechnet und für den nächsten Tag liegen die Werte, laut Brick-Aktivator höher.Dann würde Investox die komplette Historie umstellen und nicht nur den so ermittelten Handelstag separat. Angenommen die Zeitreihe beinhaltet 500 Handelstage und an jedem zweitem Handelstag würde vom Aktivator die Brickgröße neu berechnet,so hätte man in der Zeitreihe 250 Umstellungen die für den Backtest alle separat berechnet und abgespeichert werden müssten!Insofern benötigt man unterschiedliche X und Y-Achsen um die unterschiedlichen Brickgrößen darzustellen und auch das Coding mit unterschiedlichen Größen innerhalb einer Zeitreihe wird happig. Das sind meine Bedenken die mir, wenngleich sehr wünschenswerte Funktion,als nicht realisierbar erscheinen lassen!T. Dorsy(P&F-Experte) verwendet zum umstellen der X/O unterschiedliche Handelsschwellen,gemessen am Underlying. Dabei handelt es sich aber mehr um empirische Erfahrungswerte und Tabellen.Aber auch hier wird die Zeitreihe komplett umgestellt und die alten Signale in der Historie verschwinden. Was eventuell noch ein Weg wäre ist das Reversal via Aktivator einzustellen...aber auch hier ergibt sich das gleiche Problem wie o.g.!Insofern bleibt m.M. für diese Strategie (bis dato) Master-Slave, oder man setzt dementsprechend Filter ein.

Vorweg: ich fände es auch extrem Charmant, wenn Herr Knöpfel hier eine Lösung finden könnte.

Hier mal meine Gedanken zu dem Thema.
Deine Idee ist, dass die Brickgröße Tageweise gleich groß bleibt und jedem morgen aufgrund von Vortages Volas neu kalibiert wird?

John Craciun schlägt zb vor.
a) für das Traden auf Tagesbasis soll man die Brickgröße täglich neu einstellen auf:
((HHV(c,21)-llv(c,21))/2)/21 auf Tagesbars gilt dann für den nächsten Tag.
b) für Intraday Trading allerdings an der Vola der ersten eins bis zwei 5 Minuten Bars des Tages festmachen. Ohne hier einen konkreten Vorschlag zu machen.

Wie Udo schon geschrieben hat, führt das Umstellen von Brickgrößen evtl. zum rückwirkenden Verlust von Signalen oder völlig anderen Signalen wie ursprünglich.
Es sei denn Herr Knöpfel findet einen Weg, alle alten Bricks zu konservieren und nur das entstehen eines neuen Bricks abhängig zu machen von den neuen Parametern.

Aber Holla da kommt dann ein weiteres hässliches Problem ins Spiel:
Die Vola geht stark zurück, daraufhin sinkt der Brick.
Alle alten bricks werden "konserviert", aber mit der neuen Brickgröße wäre gestern ein weiterer Brick entstanden, auf der alten Brickgröße nicht.
Was wäre, wenn genau das das Entersignal gewesen wäre?
Hurra und jetzt ?

Damit das ganz auch nur ansatzweise funktionieren kann, müsste er Knöpfel quasi alles an der Renko Implementierung ändern.

Man müsste einen "ResetSchalter" haben ab dem alle alten Kurse nicht berücksichtigt werden für das entstehen neuer Bricks und die alten bricks auch so bleiben wie bisher.
Diesen Schalter würde man für die EOD Version halt mit Abschnitt(y, 1, y, m) belegen.
In der Intraday Version wird´s dann aber noch deutlich komplexer.

Die oben unter b) beschrieben Version wird man wenn überhaupt wohl aufgrund der Dualität Zeitinterval und Zeitloser Renkchart nur im Tickchart mit KOMP lösen können.
Hier wäre der Resetpunkt halt das erreichen der Minute 11 am Handelstag und die Brickgröße eine Ableitung von dailyprice(high) und dailyprice(low).

Auf jeden Fall eine nicht zu unterschätzende Aufgabe.

Hallo,

durch das geöffnete Overnight-Gap ist es theoretisch möglich, jeden Handelstag neu zu berechnen und isoliert zu betrachten(das gibt es so m.W. nur in Investox)!Der erste Brick des neuen Handelstages ist nicht handelbar,das sollte man nicht vergessen da im ersten Brick die Richtung gesucht wird!Eines der allergrößten Probleme sehe ich u.a. in der visuellen Darstellung!Unterschiedliche Brickgrößen sind vergleichbar mit Candledarstellung, die beispielsweise 10 und 30 Minuten Kerzen auf ein und der gleichen Koordinatenachse darstellen sollen! Das ist nicht nur schwierig, sondern unmöglich zu programmieren!Was mir persönlich für die bessere Auswertung der Bricks oder X/Os fehlt,ist der Zugriff auf die eigentliche Komprimierung den man beispielsweise über den Var-Trimmer ansteuern könnte. Somit müsste man nicht mehr mit Tick-Komp arbeiten was schnellere und umfangreicherer Tests zulassen würde. Änderungen des Bricks,gesteuert von Aktivatoren, sind aus jetziger Sicht lediglich mit Master-Slave Kombinationen handelbar.Hier hätte man zusätzlich die historische Kontrolle über alle Veränderungen bzw. Brickgrößen und könnte die Einzelergebnisse im Depottest zusammenführen, um das Gesamtergebnis der einzelnen Systeme zu messen!Ich gehe davon aus, das es gar nicht sooo viele Vola-Schwellen in einer Zeitreihe gibt, die eine drastische Änderung des Bricks erfordern, da sich die Intensität der Swings ständig wiederholt und somit auch die Intensitätsschwellen! Ich persönlich würde den Aktivator eher an der Handelsspanne über n-Perioden direkt, und nicht über den Vola-Indikator festmachen!