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.
Samstag, 11. Dezember 2010, 20:06
Hallo Torsten
Du kannst heute bereits über eine Master/Slave Konstruktion auf die KK Berechnungen und Indikatoren anwenden, um zu entscheiden, ob Dein HS handeln darf oder nicht.
Die wirklich realisierte KK ist doch im Investox Depot ersichtlich! Sollte diese KK signifikant vom Backtest abweichen, brauchst Du eigentlich gar nicht mehr diskutieren - dann klappt die ganze Umsetzung des Handelssystems nicht und das Ding kannst unbesehen einfach abschalten! Ja musst es sogar, weil es ja was ganz anderes handelt, als Du im Backtest erreichen wolltest. Ab, nochmal nach-entwickeln, das war wohl Murks!
Siehe oben, Master/Slave Konstruktion leistet das doch bereits.
Also jetzt sei mir mal bitte nicht böse, aber das ist ja wirklich schwach. Du hast also keine konkrete Berechnung, die Du mit der neuen Funktion ausführen willst, weil Du jetzt schon nicht weisst, nach welchen konkret Kriterien entscheiden. Intuitiv, aha. Nur besser werden soll alles.
Das scheint mir wie der Witz mit diesem Piloten, den das Klappern im Cockpit stört; er hinterlässt für den Mech einen Zettel: "etwas klappert". Natürlich schreibt der Mech zurück "etwas festgeschraubt".
.. alles sehr vage. Hast Du denn mit Master/Slave überprüft, ob so ein GD() sich wenigstens auf korrekte Signale nicht negativ auswirkt?
Du kannst heute bereits über eine Master/Slave Konstruktion auf die KK Berechnungen und Indikatoren anwenden, um zu entscheiden, ob Dein HS handeln darf oder nicht.
Bei einer solchen Bewertung würden es sehr helfen, wenn man eine graphische Unterstützung bei der angezeigten, wirklich realisierten KK hätte.
Die wirklich realisierte KK ist doch im Investox Depot ersichtlich! Sollte diese KK signifikant vom Backtest abweichen, brauchst Du eigentlich gar nicht mehr diskutieren - dann klappt die ganze Umsetzung des Handelssystems nicht und das Ding kannst unbesehen einfach abschalten! Ja musst es sogar, weil es ja was ganz anderes handelt, als Du im Backtest erreichen wolltest. Ab, nochmal nach-entwickeln, das war wohl Murks!
Im nächsten Schritt muss man entscheiden welche HS, die nächste Woche noch weiter handeln dürfen und welche ausscheiden.
Siehe oben, Master/Slave Konstruktion leistet das doch bereits.
und bisher entscheide ich das mehr oder weniger intuitiv, welches HS noch eine Chance bekommt.
Also jetzt sei mir mal bitte nicht böse, aber das ist ja wirklich schwach. Du hast also keine konkrete Berechnung, die Du mit der neuen Funktion ausführen willst, weil Du jetzt schon nicht weisst, nach welchen konkret Kriterien entscheiden. Intuitiv, aha. Nur besser werden soll alles.
Das scheint mir wie der Witz mit diesem Piloten, den das Klappern im Cockpit stört; er hinterlässt für den Mech einen Zettel: "etwas klappert". Natürlich schreibt der Mech zurück "etwas festgeschraubt".
Könnte man hier z.B. einen GD() reinlegen,
.. alles sehr vage. Hast Du denn mit Master/Slave überprüft, ob so ein GD() sich wenigstens auf korrekte Signale nicht negativ auswirkt?
Gruss
Bernd
Bernd
Sonntag, 12. Dezember 2010, 00:08
Hallo Bernd,
Die Methode ist mir bekannt, aber verwende ich nicht. Es würden dann auf dem Produktivsystem zu viele Perioden benötigt & wegen der doppelten Anz. von HS auch mindestens eine doppelte Last bedeuten, was die Anzahl der handelbaren HS zu stark einschränkt. Ich würde dann jetzt schon ein Cluster von Produktivrechner benötigen. Deshalb verwende ich keine automatisierte Abschaltung von HS, sondern mache es manuell in wöchentlichen Intervallen.
Theoretisch könnte man auch die KK des Backtest-HS zur Selektion heranziehen und natürlich stimmt diese mit dem LiveHS-KK überein. Praktisch ist es aber so, dass sich die BacktestHS auf verschieden Inv-Projekte in verschieden Verz. verteilen auf einem anderen PC befinden und das raussuche und überprüfen aufwendig ist. Deshalb würde ich gerne die LiveHS-KK verwenden, ist alles schon im OM vorhanden, kein langes suchen und so ist der Seletionsprozeß schnell erledigt.
Ich habe in dem Bereich KK-Auswertung sehr viel rumexperimentiert. Aber letzten Endes ist es doch so: KK steigt, dann darf das HS weiter laufen. KK fällt, dann stop. Sollte sich das HS zu einem späteren Zeitpunkt wieder fangen, dann wird es wieder neu aufgenommen im OM, usw.
Das mit dem GD() habe ich als einfaches Beispiel mit reingenommen, um halbwegs verständlich zu machen, worauf ich hinaus möchte. Alternativ könnte man im OM vielleicht auch eine Bewertungskennzahl der HS einführen (eventuell mit Farbschattierungen unterlegen, z.B. je grüner um so besser KK & rot wäre dann fallende KK), die eine Funktion vom Nettoprofit, Verluste, Schwankungsbreite der KK, Regelmäßigkeit der Steigung, usw. ist.
Aber das sind alles nur Ideen. Ob so etwas wirklich mal eingebaut wird ins OM hängt stark davon ab, ob ich der einzig bin der so vorgeht oder ob sich noch mehr Investox'ler mit so eine Vorgehensweise anfreunden könnten.
Viele Grüße
Sten
Zitat
Du kannst heute bereits über eine Master/Slave Konstruktion auf die KK Berechnungen und Indikatoren anwenden, um zu entscheiden, ob Dein HS handeln darf oder nicht.
Die Methode ist mir bekannt, aber verwende ich nicht. Es würden dann auf dem Produktivsystem zu viele Perioden benötigt & wegen der doppelten Anz. von HS auch mindestens eine doppelte Last bedeuten, was die Anzahl der handelbaren HS zu stark einschränkt. Ich würde dann jetzt schon ein Cluster von Produktivrechner benötigen. Deshalb verwende ich keine automatisierte Abschaltung von HS, sondern mache es manuell in wöchentlichen Intervallen.
Die wirklich realisierte KK ist doch im Investox Depot ersichtlich! Sollte diese KK signifikant vom Backtest abweichen ...
Theoretisch könnte man auch die KK des Backtest-HS zur Selektion heranziehen und natürlich stimmt diese mit dem LiveHS-KK überein. Praktisch ist es aber so, dass sich die BacktestHS auf verschieden Inv-Projekte in verschieden Verz. verteilen auf einem anderen PC befinden und das raussuche und überprüfen aufwendig ist. Deshalb würde ich gerne die LiveHS-KK verwenden, ist alles schon im OM vorhanden, kein langes suchen und so ist der Seletionsprozeß schnell erledigt.
Also jetzt sei mir mal bitte nicht böse, aber das ist ja wirklich schwach. Du hast also keine konkrete Berechnung, die Du mit der neuen Funktion ausführen willst, ...
Ich habe in dem Bereich KK-Auswertung sehr viel rumexperimentiert. Aber letzten Endes ist es doch so: KK steigt, dann darf das HS weiter laufen. KK fällt, dann stop. Sollte sich das HS zu einem späteren Zeitpunkt wieder fangen, dann wird es wieder neu aufgenommen im OM, usw.
.. alles sehr vage.
Das mit dem GD() habe ich als einfaches Beispiel mit reingenommen, um halbwegs verständlich zu machen, worauf ich hinaus möchte. Alternativ könnte man im OM vielleicht auch eine Bewertungskennzahl der HS einführen (eventuell mit Farbschattierungen unterlegen, z.B. je grüner um so besser KK & rot wäre dann fallende KK), die eine Funktion vom Nettoprofit, Verluste, Schwankungsbreite der KK, Regelmäßigkeit der Steigung, usw. ist.
Aber das sind alles nur Ideen. Ob so etwas wirklich mal eingebaut wird ins OM hängt stark davon ab, ob ich der einzig bin der so vorgeht oder ob sich noch mehr Investox'ler mit so eine Vorgehensweise anfreunden könnten.
Viele Grüße
Sten
Sonntag, 12. Dezember 2010, 00:59
Hallo Torsten
Ah, das heisst im Umkehrschluss, Du hast auch eine beträchtliche Anzahl an Handelssystemen Life, wenn die überprüfung so aufwendig ist. Verstehe. Nur mal so interesse-halber, auf wieviele Instanzen hast Du die Projekte denn Life verteilt, weil eine Instanz das möglicherweise gar nicht schafft? Setzt Du dazu ebenfalls mehrere Gateways ein wegen der begrenzten Kapazitäten der TWS und hast dann ebenso wie ich und einige andere hier das Problem mit dem hängenden Gateway? Wenn ja, wäre es nett, wenn Du auch auf der IB Feature Poll Seite voten könntest. In diesem Thread habe ich den Poll nochmals verlinkt.
Nun sehe noch weniger durch, wohin dieser Vorschlag führen soll. Ist doch schon alles da wie gewünscht; an die Life-KK kommt man mit DepotHist() dran, kann alle üblichen Investox-Berechnungen drauf anwenden, selektieren ob dieses HS heute mit darf und dann bequem per AND Bedingung das Enter Long bzw. Enter Short abklemmen. Sogar auf die Life-KK anderer HSe kannst Du zugreifen, wenn das für die Selektion irgendwie von Belang ist! Sogar alle Oder-Informationen wie Orderpreis, Return, Gebühren, Slippage, Kapitalentwicklung, was das Herz begehrt.
War es das, was Du gesucht hast, nehme ich an.
Praktisch ist es aber so, dass sich die BacktestHS auf verschieden Inv-Projekte in verschieden Verz. verteilen auf einem anderen PC befinden und das raussuche und überprüfen aufwendig ist.
Ah, das heisst im Umkehrschluss, Du hast auch eine beträchtliche Anzahl an Handelssystemen Life, wenn die überprüfung so aufwendig ist. Verstehe. Nur mal so interesse-halber, auf wieviele Instanzen hast Du die Projekte denn Life verteilt, weil eine Instanz das möglicherweise gar nicht schafft? Setzt Du dazu ebenfalls mehrere Gateways ein wegen der begrenzten Kapazitäten der TWS und hast dann ebenso wie ich und einige andere hier das Problem mit dem hängenden Gateway? Wenn ja, wäre es nett, wenn Du auch auf der IB Feature Poll Seite voten könntest. In diesem Thread habe ich den Poll nochmals verlinkt.
Deshalb würde ich gerne die LiveHS-KK verwenden, ist alles schon im OM vorhanden, kein langes suchen und so ist der Seletionsprozeß schnell erledigt.
Nun sehe noch weniger durch, wohin dieser Vorschlag führen soll. Ist doch schon alles da wie gewünscht; an die Life-KK kommt man mit DepotHist() dran, kann alle üblichen Investox-Berechnungen drauf anwenden, selektieren ob dieses HS heute mit darf und dann bequem per AND Bedingung das Enter Long bzw. Enter Short abklemmen. Sogar auf die Life-KK anderer HSe kannst Du zugreifen, wenn das für die Selektion irgendwie von Belang ist! Sogar alle Oder-Informationen wie Orderpreis, Return, Gebühren, Slippage, Kapitalentwicklung, was das Herz begehrt.
War es das, was Du gesucht hast, nehme ich an.
Gruss
Bernd
Bernd
Sonntag, 12. Dezember 2010, 01:50
Praktisch ist es aber so, dass sich die BacktestHS auf verschieden Inv-Projekte in verschieden Verz. verteilen auf einem anderen PC befinden und das raussuche und überprüfen aufwendig ist
Verzeih mir meinen bösen Kommentar:
Das ist nicht Dein Ernst? Du brauchst eine Erweiterung von Investox im ORM (von der Du noch nicht mal genau spezifizieren kannst was Sie genau machen soll, außer bunt leuchten) um Deine unzureichende interne Organisationsstruktur auszumerzen?
Deshalb würde ich gerne die LiveHS-KK verwenden, ist alles schon im OM vorhanden, kein langes suchen und so ist der Seletionsprozeß schnell erledigt.
Hat Bernd ja schon geschrieben: Depothist() sollte eigentlich zielführend sein für Deine Aufgabenstellung.
Ich habe in dem Bereich KK-Auswertung sehr viel rumexperimentiert. Aber letzten Endes ist es doch so: KK steigt, dann darf das HS weiter laufen. KK fällt, dann stop
Und wenn man das beschreiben kann wann man den Handel stopt, dann kann man es auch exemplarisch im Master/Slave Backtest validieren.
Ist der Backtest erfolgreich diesbezüglich -> Jippi.
Die Funktion zum abschalten sollte sich dann auch mit Sicherheit auch auf Depothist() ohne M/S implementieren lassen.
Sollte sich das HS zu einem späteren Zeitpunkt wieder fangen, dann wird es wieder neu aufgenommen im OM, usw.
Ne Frau die aufgehört hat zu heulen weil ich erst um 3 Uhr nach Hause gekommen bin hat sich im Volksmund nach versiegen der Tränen auch angeblich "gefangen".
Ob ich die dann noch haben will, weil mir das Theater zu viel ist ????
Den Restart des Systemes willst Du daher händisch festlegen, oder habe ich das falsch verstanden?
Automatisch geht´s mit Depothist() auf jeden Fall nicht, weil ja keine neuen Trades entstehen.
If you think it´s expensive to hire a professional, wait until you hire an amateur.
Samstag, 1. Januar 2011, 21:08
Hallo,
irgendwie habt Ihr mich nicht richtig verstanden. Ich versuche die Idee nochmal etwas detailierter zu erklären.
Mir geht es um eine Erweiterung im OM, womit Live-HS bewertet werden können und rechtzeitig vor dem Abfallen der KK abgeschaltet werden können. Es soll eine Bewertungs-Heuristik sein, die auf alle HS einheitlich angewendbar sein sollte.
Wie könnte so eine einfache Heuristik ausschauen?
-Gewinntrades sollten "belohnt" werden, z.B. +1 zu SUM dazu zählen
-Verlusttrades sollten "bestraft" werden, z.B. -1 oder -2 von SUM anziehen
-konkretes Abbruchkriterium, z.B. SUM wird negativ, oder GesamtKK negativ
-Ausnahmen: Abbruch frühestens nach dem 6. Trade, um HS einen kleinen Durchhänger am Anfang zu "verzeihen"
Beispiele:
HS1 ... läuft die KK in die richtige Richtung, dann bleibt das HS länger aktiv
HS2 ... sind es zuviele Verlusttrades, dann wird nach der "Schonfrist" schnell abgebrochen
HS3 ... liegt die KK nach dem 6.Trade immer noch im negativen Bereich, dann ist Schluß (später hätte sich die KK zwar wieder erholt, aber ...)
HS4 ... hier wurde das HS nach einer Verlustserie schnell abgeschaltet. Im nachhinein nicht so optimal, aber vielleicht läst sich die Heuristik noch verbessern. Ich bin offen für Verbesserungsvorschläge. Bestimmt läst sich da noch mehr draus machen.
Viele Grüße
Sten
PS:
Prinzipiell schon, aber das ist keine gute Softwareentwicklung, wenn man den gleichen Code an X Stellen hat. In diesem Fall muss der Bewertungscode in jedes der 10 Handelssysteme reinkopiert werden. Falls sich im nachhinein was ändert, dann muss man an 10 Stellen den Code ändern. Das ist sehr zeitaufwendig und fehleranfällig. Wäre die Bewertungsheuristik im OM, dann wäre eine Implementierung auf alle im OM laufenden HS anwendbar...
Es gibt verschiedene Möglichkeiten wie man seine Investox-Projekte organisiert. Ich habe meine Projekte nach Strategien sortiert abgelegt in verschiedenen Verzeichnissen. Zusätzlich gibt es in jedem Verzeichnis eine Versionierung, also Start bei V01. Später beseitigt man Fehler oder macht Verbesserungen und dann wird die Versionsnummer hochgezählt. Nicht immer ist die letzte Investoxprojektdatei auch die, wo das LiveHS gerade läuft.
Im Grunde genommen steckt man in einem Dilemma fest. Im EntwicklungsHS mit max. Periodenanzahl ist es einfach eine KK-Bewertung einzubauen, aber man kann darauf nicht beim LiveHS zurückgreifen, weil man aus Performancegründen die Periodenanzahl stark begrenzen muss. Also müsste man immer auf dem EntwicklungsPC im zugehörigen EntwicklungsHS nachsehen, ob die KK-Bewertung noch einen weiteren Handel des HS anrät oder nicht.
--> ist für viele HS sehr aufwendig
Die vorgeschlagene Lösung mit der HS-Heuristik-Bewertung kommt mit minimaler Periodenanzahl aus, kann auf die unterschiedlichsten HS einheitlich angewendet werden und alle Informationen wären an einer Stelle im OM konzentriert und können so schneller ausgewertet werden. Es wäre ein weiterer Baustein im HS-Systembaukasten.
irgendwie habt Ihr mich nicht richtig verstanden. Ich versuche die Idee nochmal etwas detailierter zu erklären.
Mir geht es um eine Erweiterung im OM, womit Live-HS bewertet werden können und rechtzeitig vor dem Abfallen der KK abgeschaltet werden können. Es soll eine Bewertungs-Heuristik sein, die auf alle HS einheitlich angewendbar sein sollte.
Wie könnte so eine einfache Heuristik ausschauen?
-Gewinntrades sollten "belohnt" werden, z.B. +1 zu SUM dazu zählen
-Verlusttrades sollten "bestraft" werden, z.B. -1 oder -2 von SUM anziehen
-konkretes Abbruchkriterium, z.B. SUM wird negativ, oder GesamtKK negativ
-Ausnahmen: Abbruch frühestens nach dem 6. Trade, um HS einen kleinen Durchhänger am Anfang zu "verzeihen"
Beispiele:
HS1 ... läuft die KK in die richtige Richtung, dann bleibt das HS länger aktiv
HS2 ... sind es zuviele Verlusttrades, dann wird nach der "Schonfrist" schnell abgebrochen
HS3 ... liegt die KK nach dem 6.Trade immer noch im negativen Bereich, dann ist Schluß (später hätte sich die KK zwar wieder erholt, aber ...)
HS4 ... hier wurde das HS nach einer Verlustserie schnell abgeschaltet. Im nachhinein nicht so optimal, aber vielleicht läst sich die Heuristik noch verbessern. Ich bin offen für Verbesserungsvorschläge. Bestimmt läst sich da noch mehr draus machen.
Viele Grüße
Sten
PS:
Hat Bernd ja schon geschrieben: Depothist() sollte eigentlich zielführend sein für Deine Aufgabenstellung.
Prinzipiell schon, aber das ist keine gute Softwareentwicklung, wenn man den gleichen Code an X Stellen hat. In diesem Fall muss der Bewertungscode in jedes der 10 Handelssysteme reinkopiert werden. Falls sich im nachhinein was ändert, dann muss man an 10 Stellen den Code ändern. Das ist sehr zeitaufwendig und fehleranfällig. Wäre die Bewertungsheuristik im OM, dann wäre eine Implementierung auf alle im OM laufenden HS anwendbar...
Verzeih mir meinen bösen Kommentar:
Das ist nicht Dein Ernst? Du brauchst eine Erweiterung von Investox im ORM (von der Du noch nicht mal genau spezifizieren kannst was Sie genau machen soll, außer bunt leuchten) um Deine unzureichende interne Organisationsstruktur auszumerzen?
Es gibt verschiedene Möglichkeiten wie man seine Investox-Projekte organisiert. Ich habe meine Projekte nach Strategien sortiert abgelegt in verschiedenen Verzeichnissen. Zusätzlich gibt es in jedem Verzeichnis eine Versionierung, also Start bei V01. Später beseitigt man Fehler oder macht Verbesserungen und dann wird die Versionsnummer hochgezählt. Nicht immer ist die letzte Investoxprojektdatei auch die, wo das LiveHS gerade läuft.
Im Grunde genommen steckt man in einem Dilemma fest. Im EntwicklungsHS mit max. Periodenanzahl ist es einfach eine KK-Bewertung einzubauen, aber man kann darauf nicht beim LiveHS zurückgreifen, weil man aus Performancegründen die Periodenanzahl stark begrenzen muss. Also müsste man immer auf dem EntwicklungsPC im zugehörigen EntwicklungsHS nachsehen, ob die KK-Bewertung noch einen weiteren Handel des HS anrät oder nicht.
--> ist für viele HS sehr aufwendig
Die vorgeschlagene Lösung mit der HS-Heuristik-Bewertung kommt mit minimaler Periodenanzahl aus, kann auf die unterschiedlichsten HS einheitlich angewendet werden und alle Informationen wären an einer Stelle im OM konzentriert und können so schneller ausgewertet werden. Es wäre ein weiterer Baustein im HS-Systembaukasten.
Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »sten« (1. Januar 2011, 21:38)
Sonntag, 2. Januar 2011, 00:11
Prinzipiell schon, aber das ist keine gute Softwareentwicklung, wenn man den gleichen Code an X Stellen hat. In diesem Fall muss der Bewertungscode in jedes der 10 Handelssysteme reinkopiert werden. Falls sich im nachhinein was ändert, dann muss man an 10 Stellen den Code ändern. Das ist sehr zeitaufwendig und fehleranfällig.
Das ist für mich irgendwie kein wirkliches Argument.
Den Code stopft man in einen Indikator und schon hat man nur eine Codestelle zu pflegen.
Zum Rest nur soviel (das meiste hatten wir ja schon mal hier und anderswo diskutiert) :
Ich wäre sehr froh, wenn ich ein allgemein gültiges Verfahren zum ab und wieder anstellen von Handelssystem hätte, welches Drawdowns vermindert ohne Renditepotentiale einzuschränken.
Nur bisher habe ich keines gefunden. Insofern ist für MICH die Diskussion um ein mögliches Tool, dass aus dem ORM ein HS ab und wieder anschaltet nutzlos.
Deinen Ausführungen entnehme ich, dass Du bei dem Thema auch noch ziemlich im dunklen rumstocherst.
-Ausnahmen: Abbruch frühestens nach dem 6. Trade, um HS einen kleinen Durchhänger am Anfang zu "verzeihen"
Hierzu sei die Frage erlaubt, warum ein HS ausgerechnet am Anfang einen Durchhänger haben darf?
Der Sinn hinter der Regel erschließt sich mir nicht mal Ansatzweise.
If you think it´s expensive to hire a professional, wait until you hire an amateur.
Sonntag, 2. Januar 2011, 00:31
Wie könnte so eine einfache Heuristik ausschauen?
-Gewinntrades sollten "belohnt" werden, z.B. +1 zu SUM dazu zählen
-Verlusttrades sollten "bestraft" werden, z.B. -1 oder -2 von SUM anziehen
-konkretes Abbruchkriterium, z.B. SUM wird negativ, oder GesamtKK negativ
-Ausnahmen: Abbruch frühestens nach dem 6. Trade, um HS einen kleinen Durchhänger am Anfang zu "verzeihen"
Bewertungsmatrix +1, -2 und Abbruch bei sum<0
welche Trefferquote benötigt das HS mindestens um nicht abgeschaltet zu werden?
If you think it´s expensive to hire a professional, wait until you hire an amateur.
Sonntag, 2. Januar 2011, 03:09
Hallo,
Man sucht bei der Handelssystementwicklung nach einer Ineffizienz im Markt und nutzt diese dann aus. Beim Trading wird kein Gewinn erwirtschaftet, sondern immer nur Geld umverteilt. Der Verlierer wird früh oder später seine Vorgehensweise ändern, weil er entweder Pleite ist oder einen anderen Ansatz versuchen. Deshalb funktionieren HS immer nur eine verübergehende Zeit, d.h. es scheint soetwas wie ein eingebautes Verfallsdatum bei HS zu geben.
So eine Lebenszyklus eines HS kann stark vereinfacht mit der Geschoßbahn einer Kugel verglichen werden, wenn diese schräg nach oben abgefeuert wurde. Am Anfang steigt die KK, erreicht dann irgendwann den höchsten Punkt und fällt danach ab. Leider geht das abfallen viel schneller, als der Anstieg der KK am Anfang vor sich, so dass man Gefahr läuft die realisierten Gewinne wieder vollständig zu verlieren.
Deshalb die Idee mit der Heuristik mit dem Ziel den Wendepunkt der KK möglichst gut zu erwischen und rechtzeitig das HS abzuschalten. Natürlich wird das Idealziel fast nie erreicht. Meist wird das HS zu früh außer Betrieb genommen, aber es sollte vielleicht gelingen, dass langfristig gesehen mehr vom Gewinn bleibt, bei geringerem Risiko.
Viele Grüße
Sten
Zum Rest nur soviel (das meiste hatten wir ja schon mal hier und anderswo diskutiert) :
Ich wäre sehr froh, wenn ich ein allgemein gültiges Verfahren zum ab und wieder anstellen von Handelssystem hätte, welches Drawdowns vermindert ohne Renditepotentiale einzuschränken.
Nur bisher habe ich keines gefunden. Insofern ist für MICH die Diskussion um ein mögliches Tool, dass aus dem ORM ein HS ab und wieder anschaltet nutzlos.
Man sucht bei der Handelssystementwicklung nach einer Ineffizienz im Markt und nutzt diese dann aus. Beim Trading wird kein Gewinn erwirtschaftet, sondern immer nur Geld umverteilt. Der Verlierer wird früh oder später seine Vorgehensweise ändern, weil er entweder Pleite ist oder einen anderen Ansatz versuchen. Deshalb funktionieren HS immer nur eine verübergehende Zeit, d.h. es scheint soetwas wie ein eingebautes Verfallsdatum bei HS zu geben.
So eine Lebenszyklus eines HS kann stark vereinfacht mit der Geschoßbahn einer Kugel verglichen werden, wenn diese schräg nach oben abgefeuert wurde. Am Anfang steigt die KK, erreicht dann irgendwann den höchsten Punkt und fällt danach ab. Leider geht das abfallen viel schneller, als der Anstieg der KK am Anfang vor sich, so dass man Gefahr läuft die realisierten Gewinne wieder vollständig zu verlieren.
Deshalb die Idee mit der Heuristik mit dem Ziel den Wendepunkt der KK möglichst gut zu erwischen und rechtzeitig das HS abzuschalten. Natürlich wird das Idealziel fast nie erreicht. Meist wird das HS zu früh außer Betrieb genommen, aber es sollte vielleicht gelingen, dass langfristig gesehen mehr vom Gewinn bleibt, bei geringerem Risiko.
Viele Grüße
Sten
Sonntag, 2. Januar 2011, 10:58
Hallo sten
Das ist leider nicht der Fall, höchsten vielleicht bei Dir. Mit V5 wurde Investox instanzen-fähig, und mit V6 laufen gar bis zu 24 ORM's pro Rechner. Ich bin schon mit V6 life und nutze eine ganze Anzahl Instanzen; mir würde also so eine Insel-Lösung, die nur innerhalb einer Instanz funktioniert, auch dann nichts nützen, wenn ich ein sinnvolles Konzept sehen würde, nach welchen Kriterien HSe an- und ausgeschaltet werden könnten ...
Allerdings würde ich ein zentrales ORM für alle Instanzen begrüssen (aber nur, wenn es Multicore-fähig wäre, um kein neues Nadelöhr zu haben)! Das hätte dann eine Reihe wirklicher Vorteile, z.B.
* die Cushion könnte unter Berücksichtigung von Sicherheitszuschlägen für offene Orders zentral überwacht werden
* bei überraschenden Over-Fills vieler Limit-Orders ("Abstauber-Limits") könnten die das Konto übersteigenden Orders zentral mit der höchsten Geschwindikeit, die das jeweilige API zulässt, automatisch gestrichen werden
* bei einer hohen Anzahl Investox-Instanzen benötigt man wegen der ORM-Connection heute mehrere IB Gateway; dies würde mit einem zentralen ORM i.d.R. entfallen
* kommt es zu einer Margin-Call Situation, könnte das zentrale ORM die Positionen soweit nötig nach einem vorgegebenen System abräumen statt es dem Broker zu überlassen
Wenn ich weiter nachdenke, kommen mir mit Sicherheit noch viele andere Vorteile für ein zentrales ORM; allenfalls darin würde dann der von Dir beschriebene Mechano Sinn machen - so man einen sinnvollen Algorithmus für das ein/Aus schalten finden könnte - allerdings wäre der dann so quer über alle Instanzen leider nicht backtest-fähig.
Letzteres Argument trifft natürlich auch meine anderen Argumente für ein zentrales ORM: allerdings handelt es sich bei meinen Argumenten für ein zentrales ORM um das Handling von vorgegebenen Notwendigkeiten Der Margin Call z.B. tritt halt irgendwann einmal einfach ein, wenn man das Konto mit vielen Instanzen, vielen Projekten und noch mehr HSen ausreizt und es MUSS sich drum gekümmert werden. Allerdings könnte die Margin Call Situation weitgehend im Vorfeld verhindert werden, wenn dieses zentrale ORM sich über die Margin-Belastung im Klaren ist, über die Orders im Markt und die offenen Orders, wie oben beschrieben!!!
alle Informationen wären an einer Stelle im OM konzentriert und können so schneller ausgewertet werden.
Das ist leider nicht der Fall, höchsten vielleicht bei Dir. Mit V5 wurde Investox instanzen-fähig, und mit V6 laufen gar bis zu 24 ORM's pro Rechner. Ich bin schon mit V6 life und nutze eine ganze Anzahl Instanzen; mir würde also so eine Insel-Lösung, die nur innerhalb einer Instanz funktioniert, auch dann nichts nützen, wenn ich ein sinnvolles Konzept sehen würde, nach welchen Kriterien HSe an- und ausgeschaltet werden könnten ...
Allerdings würde ich ein zentrales ORM für alle Instanzen begrüssen (aber nur, wenn es Multicore-fähig wäre, um kein neues Nadelöhr zu haben)! Das hätte dann eine Reihe wirklicher Vorteile, z.B.
* die Cushion könnte unter Berücksichtigung von Sicherheitszuschlägen für offene Orders zentral überwacht werden
* bei überraschenden Over-Fills vieler Limit-Orders ("Abstauber-Limits") könnten die das Konto übersteigenden Orders zentral mit der höchsten Geschwindikeit, die das jeweilige API zulässt, automatisch gestrichen werden
* bei einer hohen Anzahl Investox-Instanzen benötigt man wegen der ORM-Connection heute mehrere IB Gateway; dies würde mit einem zentralen ORM i.d.R. entfallen
* kommt es zu einer Margin-Call Situation, könnte das zentrale ORM die Positionen soweit nötig nach einem vorgegebenen System abräumen statt es dem Broker zu überlassen
Wenn ich weiter nachdenke, kommen mir mit Sicherheit noch viele andere Vorteile für ein zentrales ORM; allenfalls darin würde dann der von Dir beschriebene Mechano Sinn machen - so man einen sinnvollen Algorithmus für das ein/Aus schalten finden könnte - allerdings wäre der dann so quer über alle Instanzen leider nicht backtest-fähig.
Letzteres Argument trifft natürlich auch meine anderen Argumente für ein zentrales ORM: allerdings handelt es sich bei meinen Argumenten für ein zentrales ORM um das Handling von vorgegebenen Notwendigkeiten Der Margin Call z.B. tritt halt irgendwann einmal einfach ein, wenn man das Konto mit vielen Instanzen, vielen Projekten und noch mehr HSen ausreizt und es MUSS sich drum gekümmert werden. Allerdings könnte die Margin Call Situation weitgehend im Vorfeld verhindert werden, wenn dieses zentrale ORM sich über die Margin-Belastung im Klaren ist, über die Orders im Markt und die offenen Orders, wie oben beschrieben!!!
Gruss
Bernd
Bernd
Ähnliche Themen
-
Allgemeine Fragen zu Investox »-
VERKAUFE INVESTOX 5 MIT RTT und ORDER PLUS
(4. Juni 2009, 11:33)
-
- Zusatztool Order Plus! »
-
Order nicht ausgeführt...
(14. Mai 2009, 15:54)
-
- Allgemeine Fragen zu Investox »
-
automatisches Ordermodul
(21. November 2003, 20:59)
-
- Allgemeine Fragen zu Investox »
-
Software XL (Order-Modul)
(19. August 2003, 15:47)