INVESTOX-Forum

Hallo igi,

um eine Strategie zu entwickeln wäre es notwendig diese zu testen-mit anderen Worten: Investox sollte bezüglich des MM *pyramidisieren* beinhalten. Das ist aber bislang leider nicht so!Die Strategie ist m.M. nicht ganz einfach auszuwerten und funktioniert nur in Trends! Zum einen muss der Einstieg der nächsten Kontrakte exakt geplant werden und zum anderen der Abbau der Positionen widerum eine Strategie enthalten, um die eine Gewinn_Pyramide nicht wieder zu halbieren. Daher ist es oft so das eine Strategie eigentlich zwei beinhaltet-eine für das ENTRY und eine andere für das pyramidisiern! Bei P&F tut man sich etwas leichter da man Support_Resistance einfacher erkennt-was aber nicht viel hilft ohne es testen zu können!Ich halte es ehrlich gesagt ohne Backtest-Möglichkeit für zu riskant!

Hast Du schon mal mit einem FIXED RATIO eine Strategie getestet? Hier kann man mit einer zweiten Strategie Einfluss auf die Kontraktanzahl nehmen (IF_THEN_ELSE) aber nicht pyramidisieren im eigentlichen Sinn!

Zitat

aber programmieren wird heftig....

Es ist bis jetzt leider noch gar nicht möglich, Pyramidisierungen mit vertretbarem Aufwand zu programmieren.

Herr Knöpfel hatte aber hier
schon einmal geschrieben, dass die (auch von mir heiß ersehnten ) Features mittelfristig auf seiner Planungsliste stehen.

Hallo klexer,

programmierbar ist es sicherlich. Es könnte z.B.

1 Master-Handelssystem (Master hier im Sinne von dem System, dass die Signale zur Verfügung stellt und nicht selbst getradet wird) angelegt werden und zusätzlich
3 Slave-Handelssysteme (wenn Exit2 und Exit3 identisch sind- sonst 4 Slaves).

Bei dieser Variante würde sich aber-aus meiner Sicht- die Frage nach der Möglichkeit zum Backtesten stellen.

Das Backtesting dürfte sich deshalb nicht einfach gestalten, weil Du bei den 3 (bzw. 4) Slave Handelssystemen immer nur die komplette Position schließen kannst.
Slave 1 würde Dir hier also im Gewinnfall 4 Kontrakte des Master-Systems(die 4 nehme ich jetzt mal der Einfachheit halber an) nach 8 ticks schließen, Slave 2 die 4-Kontrakte aus dem Mastersystem nach 16 ticks und Slave 3 die 4 Kontrakte aus dem Mastersystem nach 20 Ticks.

Umgehen könntest Du das eigentlich nur durch 3 (bzw. 4) Master und zusätzlich 3 (bzw. 4 ) Slaves in einem Projekt. Die Performance dieser Variante wäre dann auch (über die Addition der Slave-KK) backtestbar.

Hier würde ich für mich persönlich aber (wie ich oben schon angedeutet habe) die Frage nach dem "vertretbarem Aufwand"stellen wollen.
Den "vertretbaren Aufwand" würde ich dabei auch nicht allein am Aufwand für die Programmierung festmachen, sondern auch an dem Aufwand, der im Zusammenhang mit später erforderlichen Systemänderungen / Systemwartungen bei Änderungen der Trendrichtung und/oder Trendintensität für die Anpassung des Handelssystems an das aktuelle Marktverhalten noch entsteht.

Insbesondere dann, wenn -bei anderen Pyramidisierungs-Strategien- noch gestaffelte Entries und diverse Initial-Verluststops zum Einsatz kommen sollen, könnte ich mir vorstellen, dass alles schnell etwas unübersichtlich wird und dadurch möglicherweise die Fehlerquellen steigen ?

Vielleicht fällt aber einem anderen Boardler (oder Herrn Knöpfel) noch eine elegantere Variante zur Lösung des Problems "Pyramidisieren / Teilverkäufe / Teilzukäufe ein, die aktuell auch schon umsetzbar ist ?

Hallo Bruno,

im Grunde stimmt stimme ich dir zu aber es ist m.M. auch möglich auf systematischen Weg zu pyramidieren-wenn die Software darauf abgestimmt ist!

Als Beispiel könnte man ein simples AKTION_REAKTION HS zu nennen! Dies würde so programmiert werden:

ENTER LONG[primär]~~Formel xy [AKTION]

erster Zukauf wenn Momentum<100[Reaktion]im laufenden trade ist!

falls Stopp nicht erreicht wird dann kaufe zweiten Kontrakt wenn Momentum erneut <100[Reaktion]im laufenden trade ist usw...

Das Stopp Management ist separat zu programmieren! Man kann es vom aktuellen gesamt Depot Stand abhängig machen oder wie einen Trailing_Stopp nachziehen!Aber wie schon geschrieben benötigt man dazu ein flexibel programmiertes Feature!Flexibel deshalb, weil man auf unterschiedlichste Arten pyramidieren kann!

Übrigens kann man diskretionäres pyramidieren mittels der Überwachungs_Trade_Linie gut optimieren und überwachen!

Hallo Bruno,

ich dachte ich könne Dich zum Systemhandel und programmieren überreden....

Spass beiseite-an dem einfachen Zukauf_Modell infolge einer Reaktion habe ich versucht ein einfaches mech. Modell darzustellen! In der Regel könnte man es z.B. bei Elliot Wave oder 1-2-3 Break Strategien so anwenden nur dass das MM-Regelwerk komplexer ist und aufwendiger programmiert werden muss!

Andere Modelle wie Teilzukäufe/Teilverkäufe(Aktien;Zertifikate ect.),verknüpft mit anderen Regelwerken und gleichzeiter Abbau mittels Stopp Varianten, müssen andere Regeln enthalten und hier kann es in der Tat recht komplex werden! Das Auge ist hier in vielerlei Hinsicht wesentlich flexibler! Aber es ist bei Systemen oft so: Ideen die scheinbar sehr simpel sind, benötigen plötzlich eine Seite Programmierzeilen!

>>Aber wenn ich das richtig sehe, wird in deinem Beispiel nicht >>pyramidisiert, sondern die Position einfach linear aufgestockt ?

Im gewissen Sinn sehe ich das schon als pyramidieren denn bei einer Zukauf-Strategie wird m.M. linear sprich im (möglichen) Trend aufgestockt da die Strategie in dem Umfeld meiner Ansicht am besten funktioniert!Leider sind die Märkte nicht mehr so "trendig" wie noch vor einigen Jahren aber man findet beispielsweise bei Aktien immer wieder Gelegenheiten.
Eine andere Möglichkeit wäre, ein Aktienpaket zu kaufen und beim erreichen errechneter Kursziele den Depotanteil mittels Teilerkäufe zu verringern.

Aber wie schon geschrieben sind sie Strategien vielfältig!In Bezug auf berechnetes MM/RM hat eine mathematisch backgetestete Startegie (in Bezug auf das ENTRY) m.M. einen gewissen Vorteil vs diskretionäer da man die STOPP,-EXIT Levels besser kontrollieren,justieren und berechnen kann!

Schönes Wochenende!