Samstag, 10. März 2012, 18:57
Hallo Fido
Das ist leicht möglich. Definiere mit const eine oder mehrere Optimierungsvariable, die kannst Du im hinteren Teil von Komp() reinwerfen. Zahlen gehen unmittelbar, andere Zeichen (% T usw.) über us .. as (siehe Doku zu const).
Das Problem hier ist, dass die so per Robtest oder Optimierung gefundenen Werte zu einem bestimmten Markt (bestehend aus Index-Stand und Volatilität) passen. Ändern sich diese Gegenbenheiten (nach einer Rally, einem Crash, durch implizite Intermarketbeziehungen zu Öl, EURUSD usw., muss man - Du ahnst es schon: neu Optimieren.
D.h. aktuell ist kein selbst-adaptiver Prozess programmierbar (PS *), in dem man z.B. die Renko-Komprimierungsseinstellung über eine ART() Funktion o.ä. nachführt (weil in den Komprimierungseinstellungen nur const zugelassen ist, nicht calc). In der Folge bedeutet das, dass man sich mit Renko Systemen etwas baut, das man nach dem going-Life, also im späteren Betrieb, ständig nach-optimieren oder robusten muss. Manche machen das gerne, für mich ist wöchentliches oder sogar nur monatliches nachoptimieren aus mehreren Gründen undenkbar (die Gründe wären aber wieder eine ganz andere Geschichte, das spare ich mir hier mal).
Das ist auch der Grund, warum ich Renko in der aktuellen Form leider nicht verwenden kann. Wenn ständiges nachoptimieren kein Thema bei Dir ist (manche machen das sogar gerne, in der Hoffnung, die besten Einstellungen für z.B. die nächste Handelswoche zu finden, d.h. ich äussere mich hier ausdrücklich nicht nachteilig über diesen Ansatz; nur für mein Vorgehen passen die derzeit verfügbaren Möglichkeiten der starren Renko-Komprimierung nicht), dann kannst Du wie oben vorgezeichnet die Renko Einstellungen durchaus robusten und optimieren.
Was den möglichen Zukunftsblick betrifft, da ist mir in Deinem Conding nichts auf den ersten Blick aufgefallen; vielleicht fehlt noch anderweitiges Coding, das eine Rolle spielt; sonst müsste wohl mal ein gestandener Renko Anwender da drüber gucken.
PS *: natürlich wäre eine Hilfslösung, dass man sich z.B. 3 oder mehr Systeme programmiert für die verschiedene volatilitäts-Stufen entsprechend den Konjunkturzyklen. Über einen Filter wäre nur jeweils ein System zu einer Zeit aktiv, und für dieses hättest Du die "optimalen" Einstellungen robustet oder optimiert. Nachteile: a) n mal Coding pflegen, wenn Du auch nur eine einzelne gemeinsame Sache ausser den Renko-Einstellungen ändern willst. b) das Projekt braucht im Life Betrieb n Mal CPU Power, und ist doch nur mit einem HS jeweils im Markt. c) es würden mir noch weitere Nachteile einfallen, lassen wir das mal.
wie könnte man hier die Renkoeinstellung optimieren bzw. robusten.
Das ist leicht möglich. Definiere mit const eine oder mehrere Optimierungsvariable, die kannst Du im hinteren Teil von Komp() reinwerfen. Zahlen gehen unmittelbar, andere Zeichen (% T usw.) über us .. as (siehe Doku zu const).
Das Problem hier ist, dass die so per Robtest oder Optimierung gefundenen Werte zu einem bestimmten Markt (bestehend aus Index-Stand und Volatilität) passen. Ändern sich diese Gegenbenheiten (nach einer Rally, einem Crash, durch implizite Intermarketbeziehungen zu Öl, EURUSD usw., muss man - Du ahnst es schon: neu Optimieren.
D.h. aktuell ist kein selbst-adaptiver Prozess programmierbar (PS *), in dem man z.B. die Renko-Komprimierungsseinstellung über eine ART() Funktion o.ä. nachführt (weil in den Komprimierungseinstellungen nur const zugelassen ist, nicht calc). In der Folge bedeutet das, dass man sich mit Renko Systemen etwas baut, das man nach dem going-Life, also im späteren Betrieb, ständig nach-optimieren oder robusten muss. Manche machen das gerne, für mich ist wöchentliches oder sogar nur monatliches nachoptimieren aus mehreren Gründen undenkbar (die Gründe wären aber wieder eine ganz andere Geschichte, das spare ich mir hier mal).
Das ist auch der Grund, warum ich Renko in der aktuellen Form leider nicht verwenden kann. Wenn ständiges nachoptimieren kein Thema bei Dir ist (manche machen das sogar gerne, in der Hoffnung, die besten Einstellungen für z.B. die nächste Handelswoche zu finden, d.h. ich äussere mich hier ausdrücklich nicht nachteilig über diesen Ansatz; nur für mein Vorgehen passen die derzeit verfügbaren Möglichkeiten der starren Renko-Komprimierung nicht), dann kannst Du wie oben vorgezeichnet die Renko Einstellungen durchaus robusten und optimieren.
Was den möglichen Zukunftsblick betrifft, da ist mir in Deinem Conding nichts auf den ersten Blick aufgefallen; vielleicht fehlt noch anderweitiges Coding, das eine Rolle spielt; sonst müsste wohl mal ein gestandener Renko Anwender da drüber gucken.
PS *: natürlich wäre eine Hilfslösung, dass man sich z.B. 3 oder mehr Systeme programmiert für die verschiedene volatilitäts-Stufen entsprechend den Konjunkturzyklen. Über einen Filter wäre nur jeweils ein System zu einer Zeit aktiv, und für dieses hättest Du die "optimalen" Einstellungen robustet oder optimiert. Nachteile: a) n mal Coding pflegen, wenn Du auch nur eine einzelne gemeinsame Sache ausser den Renko-Einstellungen ändern willst. b) das Projekt braucht im Life Betrieb n Mal CPU Power, und ist doch nur mit einem HS jeweils im Markt. c) es würden mir noch weitere Nachteile einfallen, lassen wir das mal.
Gruss
Bernd
Bernd
Ähnliche Themen
-
Praktischer Einsatz von Handelssystemen »-
nahezu perfektes hs!! aber möglicherweise schauts in die zukunft
(8. November 2007, 16:21)
-
- Point & Figure / Renko »
-
Renko auf Tick und vorkomprimierter indikator
(14. Juni 2006, 13:30)
-
- Allgemeine Fragen zu Investox »
-
Renko Brick Linien
(28. Juni 2005, 17:54)
-
- Zusatztool Order Plus! »
-
Orm/p&f
(31. Januar 2005, 12:32)
-
- Allgemeine Fragen zu Investox »
-
Renkochart
(12. März 2004, 10:27)