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.
Freitag, 21. August 2009, 13:50
Hallo Sonja,
Soweit habe ich jetzt noch gar nicht gedacht.
Ich wollte einfach nur eine Pyramide im Gewinnfall aufbauen von 1 bis n. Damit nicht gleich am Anfang des Trades die Pyramide in die Höhe schießt und mir bei einen Kursschwenk auf die Füße fällt, möchte ich das Aufstocken sinnvoll verzögern. Eine praktikable Strategie scheint mir zu sein immer zu warten, bis die vorhergende Stufe mit Gewinn ausgestoppt werden würde.
Dadurch müsste selbst wenn es ganz schlimm kommt, fast immer noch etwas vom Gewinn hängen bleiben, egal wie hoch die Pyramide bereits ist.
Das ist aus meiner Sicht der einfachste Fall, um Pyramiden später auch mal real einsetzen zu können, bei einem noch vertretbaren Risiko.
Vielleicht kann man die Stops noch erweitern, um einen Hacken der eine Erhöhung der Stückzahl nur zulässt, wenn die vorhergende Stufe in Gewinn und man müsste dann das Stoplevel als Calc-Berechnung oder als globale Variable mit übergeben.
Wäre eine schöne Sache.
Viele Grüße
Torsten
Zitat
Eine Rückpyramidisierung
Soweit habe ich jetzt noch gar nicht gedacht.
Ich wollte einfach nur eine Pyramide im Gewinnfall aufbauen von 1 bis n. Damit nicht gleich am Anfang des Trades die Pyramide in die Höhe schießt und mir bei einen Kursschwenk auf die Füße fällt, möchte ich das Aufstocken sinnvoll verzögern. Eine praktikable Strategie scheint mir zu sein immer zu warten, bis die vorhergende Stufe mit Gewinn ausgestoppt werden würde.
Dadurch müsste selbst wenn es ganz schlimm kommt, fast immer noch etwas vom Gewinn hängen bleiben, egal wie hoch die Pyramide bereits ist.
Das ist aus meiner Sicht der einfachste Fall, um Pyramiden später auch mal real einsetzen zu können, bei einem noch vertretbaren Risiko.
Vielleicht kann man die Stops noch erweitern, um einen Hacken der eine Erhöhung der Stückzahl nur zulässt, wenn die vorhergende Stufe in Gewinn und man müsste dann das Stoplevel als Calc-Berechnung oder als globale Variable mit übergeben.
Wäre eine schöne Sache.
Viele Grüße
Torsten
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »sten« (21. August 2009, 14:11)
Freitag, 21. August 2009, 17:35
@Sonja
Ich glaube das man für diese Funktion die Pyramiden nicht über die Stopps steuern dürfte sondern eine separate Pyramidensteuerung dem System zugeführt werden müsste! Der Verbund mit den Stopps ist für diese Variante meiner Ansicht nicht geeignet! Die Re-Pyramidisierung könnte man eventuell über eine Schleife steuern. Das heißt, wenn der Trade nicht komplett beendet wurde beginnt die Pyramidenstrategie einfach wieder von vorne. Leider kann man das nicht prozentual mit dem bis dahin angehäuften Kapital steuern denn sonst könnte man eventuell noch mehr Kontrakte draufpacken. Investox müsste aber dann nach bestimmtem Vorgaben das Moneymanagement vollkommen automatisch steuern. Dazu bräuchte man aber die Möglichkeit, eine Regelwerk in einem Script oder via Interface geschrieben, das die Eckpunkte vorgibt! Alles vorher genannte ist bislang nicht realisierbar!
@Torsten
Vielleicht wäre es machbar, die von Dir beschriebenen Möglichkeiten zu den bisherigen Pyramiden-Einstellungen intern zuzufügen! Schlage es doch einfach mal Knöpfel Software so vor...
Bezüglich Pyramiden:es sollte eine Lösung zur Kopplung/Entkopplung diverser Pyramidengeflechte ermöglicht werden.
Ich glaube das man für diese Funktion die Pyramiden nicht über die Stopps steuern dürfte sondern eine separate Pyramidensteuerung dem System zugeführt werden müsste! Der Verbund mit den Stopps ist für diese Variante meiner Ansicht nicht geeignet! Die Re-Pyramidisierung könnte man eventuell über eine Schleife steuern. Das heißt, wenn der Trade nicht komplett beendet wurde beginnt die Pyramidenstrategie einfach wieder von vorne. Leider kann man das nicht prozentual mit dem bis dahin angehäuften Kapital steuern denn sonst könnte man eventuell noch mehr Kontrakte draufpacken. Investox müsste aber dann nach bestimmtem Vorgaben das Moneymanagement vollkommen automatisch steuern. Dazu bräuchte man aber die Möglichkeit, eine Regelwerk in einem Script oder via Interface geschrieben, das die Eckpunkte vorgibt! Alles vorher genannte ist bislang nicht realisierbar!
@Torsten
Vielleicht wäre es machbar, die von Dir beschriebenen Möglichkeiten zu den bisherigen Pyramiden-Einstellungen intern zuzufügen! Schlage es doch einfach mal Knöpfel Software so vor...
Happy Trading
Samstag, 22. August 2009, 09:39
Hallo,
Ein interne Integration wäre natürlich super, aber ist eher unwahrscheinlich. Wir sind viele und jeder von uns hat spezielle Wünsche. Alle umzusetzen und in Investox fest einzubauen ist nicht möglich.
Ich überlege mir jetzt schon seit Tagen, ob man es vielleicht doch irgendwie mit dem derzeit vorhandenen umsetzen kann. Wenn man das HS ganz stark vereinfacht, d.h.:
- nur einen Trade pro Tag zulassen und immer zum Open des Tages einsteigen
- der Trade kann beliebig aufgestockt werden (aber die Position wird niemals reduziert)
- das Aufstocken erfolgt nur, wenn sich die Stoplinie verengt, d.h. mit Ref(stoplinie, -2)<>Ref(stoplininie, -1) ... so kann man auch diese Stelle identifizieren
Dann kann man die Entrykurse ermitteln über DailyKurs(O) (oder so ähnlich heißt der Befehl) und die AufstockungEntrykurse über eine ValueWhen()-Konstruktion.
Das woran ich noch scheitere ist die Unterscheidung zwischen Entry in die Position und Aufstocken der Position. Am einfachsten wäre es wenn man soetwas wie einen TagesTradezähler hat, der bei 1 beginnt (der Einstieg in die Position) und mit jeder Aufstockung um +1 erhöht wird.
Dann könnte man die noch fehlenden Entrykurs wie folgt ermitteln:
Calc entryKurs: If(TagesTradezähler=1, DailyKurs(O), ValueWhen(xxx,yyy,1,V));
Der Knackpunkt ist also "nur noch" einen TagesTradezähler zu bauen.
Hat jemand vielleicht da eine Idee?
Danke.
Viele Grüße
Torsten
Vielleicht wäre es machbar, die von Dir beschriebenen Möglichkeiten zu den bisherigen Pyramiden-Einstellungen intern zuzufügen! Schlage es doch einfach mal Knöpfel Software so vor...
Ein interne Integration wäre natürlich super, aber ist eher unwahrscheinlich. Wir sind viele und jeder von uns hat spezielle Wünsche. Alle umzusetzen und in Investox fest einzubauen ist nicht möglich.
Ich überlege mir jetzt schon seit Tagen, ob man es vielleicht doch irgendwie mit dem derzeit vorhandenen umsetzen kann. Wenn man das HS ganz stark vereinfacht, d.h.:
- nur einen Trade pro Tag zulassen und immer zum Open des Tages einsteigen
- der Trade kann beliebig aufgestockt werden (aber die Position wird niemals reduziert)
- das Aufstocken erfolgt nur, wenn sich die Stoplinie verengt, d.h. mit Ref(stoplinie, -2)<>Ref(stoplininie, -1) ... so kann man auch diese Stelle identifizieren
Dann kann man die Entrykurse ermitteln über DailyKurs(O) (oder so ähnlich heißt der Befehl) und die AufstockungEntrykurse über eine ValueWhen()-Konstruktion.
Das woran ich noch scheitere ist die Unterscheidung zwischen Entry in die Position und Aufstocken der Position. Am einfachsten wäre es wenn man soetwas wie einen TagesTradezähler hat, der bei 1 beginnt (der Einstieg in die Position) und mit jeder Aufstockung um +1 erhöht wird.
Dann könnte man die noch fehlenden Entrykurs wie folgt ermitteln:
Calc entryKurs: If(TagesTradezähler=1, DailyKurs(O), ValueWhen(xxx,yyy,1,V));
Der Knackpunkt ist also "nur noch" einen TagesTradezähler zu bauen.
Hat jemand vielleicht da eine Idee?
Danke.
Viele Grüße
Torsten
Samstag, 22. August 2009, 12:53
Hallo Udo,
Die Pyramiden sind aber aktuell eben nun mal über Stops gesteuert und das funtioniert (auch als Einzel-Geflecht)ja soweit auch ganz gut.
Es würde auch mehr machbar sein, wenn unterschiedliche Kopplungen im Stopmanagement möglich wären.
Praktisches Beispiel zu meinen Überlegungen (degressive Pyramiden ; EUR/USD):
1. Gewinnrichtung , (Trade läuft erwartungsgemäß positiv):
Enter mit 500k ... nach 30 Pips Reduktion nach 300K ... nach weiteren 30 Pips erneute Reduktion nach 100K .... diese laufen dann in Endgewinnstop. Soweit der Idealfall.
Wird durch INV super abgewickelt. Auch eine ggf. Kopplung mit V-Stops ... kein Problem.
2.Verlustrichtung (Kurse bewegen sich unterhalb des ursprünglichen TradeEntryprice)
ein Stop bei minus 30Pips reduziert von 500K nach TWS-Trademinimum (25K) ... rennt somit nicht mit vollen 500K in den endgültigen Verluststop. Das funktioniert auch gut.
An diesen Stop will ich aber eine Repyramidisierung hängen, die bei Kursrückkehr nach z.B. minus 20Pips wieder meine 500K in Gewinnrichtung setzt. Und dieses funktioniert eben nur
bedingt, weil eine Kopplung an Folgestops (unter 1. beschrieben) erfolgt, sprich die Reduktionen in Gewinnrichtung werden immer erneut revidiert nach 500K.
Aus meiner Sicht wäre es einfach, indem man dem System sagt: Kopplung ausschließlich an Stop Nr.5 /6 /7 oder oder Stop Nr.xyz falls im Def-Bereich : Stopbezeichnung.
Alternativ (leidiges, ewiges Thema) aktuellen Initial-TradeEntryprice herausführen, dann kann jeder Stop (nicht AWS !!) hieran festgemacht werden wenn gewünscht und wenn nicht, dann ist er eben an den Pyramiden-Entries der Folgestops gekoppelt. Sowieso unverständlich, daß TEP von AWS genutzt werden kann und dieses global nicht möglich sein soll ... paßt auch hierzu:
sag das nicht ... wo ein Wille ist ... auch Intraday-Stops waren nicht realisierbar (1 Jahr lang gabs nur entsprechende OHLC - Diskussionen), oder diverse ORM-Geschichten , etc.etc.
AK kann alles !
Sorry Sten,
ist nicht ganz das, was du im Urthema wolltest , eine Überlegung wert, zu degressiver Pyramidisierung mit entsprechender Verlust-Strategie ist es aber sicherlich auch für dich , oder?
Die aggressive Variante brachte in meinen Tests immer erheblich weniger. Ist aber abhängig der Enter-Strategie. Es ist aber meistens so, daß die Rasanz der Kursentwicklung zunehmend abnimmt, mit entsprechenden Folgen bei aufbauenden Pyramiden. Aber wie gesagt, idividuelle Ansichtssache.
Schönes WE @ all
Ich glaube das man für diese Funktion die Pyramiden nicht über die Stopps steuern dürfte sondern eine separate Pyramidensteuerung dem System zugeführt werden müsste!
Die Pyramiden sind aber aktuell eben nun mal über Stops gesteuert und das funtioniert (auch als Einzel-Geflecht)ja soweit auch ganz gut.
Es würde auch mehr machbar sein, wenn unterschiedliche Kopplungen im Stopmanagement möglich wären.
Praktisches Beispiel zu meinen Überlegungen (degressive Pyramiden ; EUR/USD):
1. Gewinnrichtung , (Trade läuft erwartungsgemäß positiv):
Enter mit 500k ... nach 30 Pips Reduktion nach 300K ... nach weiteren 30 Pips erneute Reduktion nach 100K .... diese laufen dann in Endgewinnstop. Soweit der Idealfall.
Wird durch INV super abgewickelt. Auch eine ggf. Kopplung mit V-Stops ... kein Problem.
2.Verlustrichtung (Kurse bewegen sich unterhalb des ursprünglichen TradeEntryprice)
ein Stop bei minus 30Pips reduziert von 500K nach TWS-Trademinimum (25K) ... rennt somit nicht mit vollen 500K in den endgültigen Verluststop. Das funktioniert auch gut.
An diesen Stop will ich aber eine Repyramidisierung hängen, die bei Kursrückkehr nach z.B. minus 20Pips wieder meine 500K in Gewinnrichtung setzt. Und dieses funktioniert eben nur
bedingt, weil eine Kopplung an Folgestops (unter 1. beschrieben) erfolgt, sprich die Reduktionen in Gewinnrichtung werden immer erneut revidiert nach 500K.
Aus meiner Sicht wäre es einfach, indem man dem System sagt: Kopplung ausschließlich an Stop Nr.5 /6 /7 oder oder Stop Nr.xyz falls im Def-Bereich : Stopbezeichnung.
Alternativ (leidiges, ewiges Thema) aktuellen Initial-TradeEntryprice herausführen, dann kann jeder Stop (nicht AWS !!) hieran festgemacht werden wenn gewünscht und wenn nicht, dann ist er eben an den Pyramiden-Entries der Folgestops gekoppelt. Sowieso unverständlich, daß TEP von AWS genutzt werden kann und dieses global nicht möglich sein soll ... paßt auch hierzu:
Alles vorher genannte ist bislang nicht realisierbar!
sag das nicht ... wo ein Wille ist ... auch Intraday-Stops waren nicht realisierbar (1 Jahr lang gabs nur entsprechende OHLC - Diskussionen), oder diverse ORM-Geschichten , etc.etc.
AK kann alles !
Sorry Sten,
ist nicht ganz das, was du im Urthema wolltest , eine Überlegung wert, zu degressiver Pyramidisierung mit entsprechender Verlust-Strategie ist es aber sicherlich auch für dich , oder?
Die aggressive Variante brachte in meinen Tests immer erheblich weniger. Ist aber abhängig der Enter-Strategie. Es ist aber meistens so, daß die Rasanz der Kursentwicklung zunehmend abnimmt, mit entsprechenden Folgen bei aufbauenden Pyramiden. Aber wie gesagt, idividuelle Ansichtssache.
Schönes WE @ all
Samstag, 22. August 2009, 23:50
Hallo Sonja
Klar, ich habe mit meiner Aussage Bezug auf Veränderungswünsche von Dir genommen aber das oben stehende ist Fakt-zweifelsohne!
Siehe Antwort1-bezugnehmend!
Das meinte ich grundsätzlich mit "Schleife". Was mir persönlich fehlen würde, ist ein optimales MM/RM Bezug nehmend auf das noch verfügbare Kapital (frei und Buchgewinn/Verlust) und die sich daraus errechnete Positionsgröße für den "Re-Start"!
Script via Schleife? Es ist, so wie ich es verstanden haben immer wieder ein konstanter Ablauf?
Ich wollte damit nicht sagen das es nicht realisierbar wäre (kann ich auch gar nicht) oder AK es nicht programmieren kann (diese Behauptung wäre mehr als vermessen!) sondern das es noch nicht realisierbar ist denn... "" ... wo ein Wille ist ..."" kann auch etwas realisiert werden...:)
Ich wünsche ebenfalls ein schönes Wochenende!
Die Pyramiden sind aber aktuell eben nun mal über Stops gesteuert und das funtioniert (auch als Einzel-Geflecht)ja soweit auch ganz gut.
Klar, ich habe mit meiner Aussage Bezug auf Veränderungswünsche von Dir genommen aber das oben stehende ist Fakt-zweifelsohne!
Es würde auch mehr machbar sein, wenn unterschiedliche Kopplungen im Stopmanagement möglich wären.
Siehe Antwort1-bezugnehmend!
An diesen Stop will ich aber eine Repyramidisierung hängen, die bei Kursrückkehr nach z.B. minus 20Pips wieder meine 500K in Gewinnrichtung setzt. Und dieses funktioniert eben nur bedingt, weil eine Kopplung an Folgestops (unter 1. beschrieben) erfolgt, sprich die Reduktionen in Gewinnrichtung werden immer erneut revidiert nach 500K.
Das meinte ich grundsätzlich mit "Schleife". Was mir persönlich fehlen würde, ist ein optimales MM/RM Bezug nehmend auf das noch verfügbare Kapital (frei und Buchgewinn/Verlust) und die sich daraus errechnete Positionsgröße für den "Re-Start"!
Aus meiner Sicht wäre es einfach, indem man dem System sagt: Kopplung ausschließlich an Stop Nr.5 /6 /7 oder oder Stop Nr.xyz falls im Def-Bereich : Stopbezeichnung.
Script via Schleife? Es ist, so wie ich es verstanden haben immer wieder ein konstanter Ablauf?
sag das nicht ... wo ein Wille ist ... auch Intraday-Stops waren nicht realisierbar (1 Jahr lang gabs nur entsprechende OHLC - Diskussionen), oder diverse ORM-Geschichten , etc AK kann alles !
Ich wollte damit nicht sagen das es nicht realisierbar wäre (kann ich auch gar nicht) oder AK es nicht programmieren kann (diese Behauptung wäre mehr als vermessen!) sondern das es noch nicht realisierbar ist denn... "" ... wo ein Wille ist ..."" kann auch etwas realisiert werden...:)
Ich wünsche ebenfalls ein schönes Wochenende!
Happy Trading
Sonntag, 23. August 2009, 12:15
Hallo,
Sorry, hatte ich überlesen gehabt und erst jetzt beim durcharbeiten der E-Mails als Antwort auf meine Anfrage gefunden.
Ja, so habe ich es jetzt mal umgesetzt, eine globale Variable für long, die andere für short. Darüber Robustheitstest laufen lassen und konnte so das HS noch etwas profitabler machen.
ABER:
Das ganz ist wieder sehr schön optimiert auf die Vergangenheit und solange sich der Markt nicht ändert, ist alles besten. Aber der Markt wird sich ändern und deshalb suche ich nach Lösungswegen, die ohne Optimierungsvariablen auskommen und sich autoadaptiv an das jeweilige Markverhalten anpassen und somit ohne Neuoptimierung in allen Markphasen funktionieren sollten.
Ist der Markt stark und trendig, dann wird schnell ein neues Stoplevel erreicht, wo alle bis dahin gekauften Kontrakte mit Gewinn verkauft werden können. Dann wird der nächste Kontrakt gekauft, und so wird aggresiv immer mehr dazu gekauft, aber immer mit Sicherheitsnetz.
Ist der Markt schwach, dann wird es länger dauern bis das profitable Stoplevel erreicht wird und der Nachkauf wird automatisch verzögert bzw. sogar im Extremfall ganz ausgesetzt.
Diese Idee hätte ich mit der angesprochenen Pyramidisierungsvariante gerne man näher überprüft, ob sich im Backtest die Idee mit konkreten Fakten bestätigen läßt oder doch nur eine schöne Wunschvorstellung ist/bleibt.
Viele Grüße
Torsten
es gibt ja die Stop-Zusatzbedingung "Mindestgewinn". Warum hilft das hier nicht weiter?
Sorry, hatte ich überlesen gehabt und erst jetzt beim durcharbeiten der E-Mails als Antwort auf meine Anfrage gefunden.
Ja, so habe ich es jetzt mal umgesetzt, eine globale Variable für long, die andere für short. Darüber Robustheitstest laufen lassen und konnte so das HS noch etwas profitabler machen.
ABER:
Das ganz ist wieder sehr schön optimiert auf die Vergangenheit und solange sich der Markt nicht ändert, ist alles besten. Aber der Markt wird sich ändern und deshalb suche ich nach Lösungswegen, die ohne Optimierungsvariablen auskommen und sich autoadaptiv an das jeweilige Markverhalten anpassen und somit ohne Neuoptimierung in allen Markphasen funktionieren sollten.
Ist der Markt stark und trendig, dann wird schnell ein neues Stoplevel erreicht, wo alle bis dahin gekauften Kontrakte mit Gewinn verkauft werden können. Dann wird der nächste Kontrakt gekauft, und so wird aggresiv immer mehr dazu gekauft, aber immer mit Sicherheitsnetz.
Ist der Markt schwach, dann wird es länger dauern bis das profitable Stoplevel erreicht wird und der Nachkauf wird automatisch verzögert bzw. sogar im Extremfall ganz ausgesetzt.
Diese Idee hätte ich mit der angesprochenen Pyramidisierungsvariante gerne man näher überprüft, ob sich im Backtest die Idee mit konkreten Fakten bestätigen läßt oder doch nur eine schöne Wunschvorstellung ist/bleibt.
Viele Grüße
Torsten
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »sten« (23. August 2009, 12:31)
Ähnliche Themen
-
Kritik, Anregungen und Fragen zum Board »-
Noch Fragen?
(1. September 2002, 15:37)