Stop Engine

Eröffnet von ReneRose im Board Handelssysteme mit Equilla

Seitenlänge102030
Seite 1 von 2612345
#251: 14.06.2010 13:21 stock-profi
Der Beitrag wurde vom Verfasser bearbeitet. Originalbeitrag anzeigen.
In #219 habe ich den trailStop trailTrend vorgestellt, der sich für ein trendfolgendes Handelssystem eignet.
Ich zitiere:
Geht der Trader davon aus, dass im Markt ein Trend entsteht, so rechnet er mit einer Folge von Bewegungen und Korrekturen. Jeder Bewegung folgt eine Korrektur, in einem Aufwärtstrend liegt das Tief einer Korrektur höher als das Tief der vorangegangenen Korrektur und das Hoch einer Bewegung höher als das Hoch der vorangegangenen Bewegung.

Um beim Handel des Trends einen logischen Stop zu finden, macht sich der Trader diesen Aufbau aus Bewegung und Korrektur zunutze. Beim Einstieg setzt er den ersten Stop auf das Tief der letzten Korrektur. Das Tief der nächsten Korrektur ist erst bekannt, wenn nach dem Einstieg ein neues lokales Hoch erreicht wurde und wenn dieses in der Folge überschritten wird. Das tiefste Tief zwischen diesen beiden Punkten ist dann das Tief der nächsten Korrektur und damit der nächste Stop.


Ich habe dieses tiefste Tief zwischen dem lokalen Hoch und dem nächsten Hoch bisher ermittelt, indem ich das lokale Hoch ausgeklammert und das nächste Hoch eingeschlossen habe. Das funktioniert auch in der Mehrzahl der Fälle ganz gut, denn es ist unwahrscheinlich, dass das tiefste Tief ausgerechnet schon beim lokalen Hoch eintritt oder dass bei einem neuen Hoch gleichzeitig ein tiefstes Tief verzeichnet wird.

Allerdings bedeutet „unwahrscheinlich“ nicht unmöglich. Insbesondere beim Arbeiten in einem Wochenchart und mit einer engen Korrekturdefinition (correction = 1) sind mir folgende Dinge aufgefallen:

1. Es kommt tatsächlich vor, dass das tiefste Tief schon beim lokalen Hoch eintritt. Der Logik nach ist es nur dann zu berücksichtigen, wenn es nach dem Hoch erreicht wird. Da über die Reihenfolge innerhalb eines Stabes nichts bekannt ist, treffe ich eine Verlaufsannahme, die meines Wissens auch in der trading engine von TS standard edition enthalten ist:

Befindet sich das open in der oberen Hälfte der Kursspanne des Stabes, nehme ich den Verlauf open, high, low, close an. Befindet sich das open in der unteren Hälfte der Kursspanne des Stabes , nehme ich den Verlauf open, low, high, close an.

Das tiefste Tief beim lokalen Hoch wird nur berücksichtigt, wenn es nach dem Hoch erreicht wird, nach der Verlaufsannahme also nur, wenn das open sich in der oberen Hälfte des Stabes befindet.

2. Ebenso kommt es vor, dass das tiefste Tief am anderen Ende des Chartausschnitts beim nächsten Hoch erreicht wird. Hier sollte es nur berücksichtigt werden, wenn es vor dem Hoch erreicht wird, nach der Verlaufsannahme also nur dann, wenn das open in der unteren Hälfte des Stabes liegt. Bisher habe ich es immer berücksichtigt.

Neben diesen beiden Punkten habe ich noch folgende Ergänzungen vorgenommen:

3. In der Anzeige unterscheide ich jetzt local High (lH) und new High (nH).

4. In einem laufenden Trade ist es interessant zu sehen, ob bei einer Abwärtsentwicklung der Kurse nach einem lokalen Hoch schon eine Korrektur eingetreten ist. Deswegen kennzeichne ich den ersten Kursstab, bei dem eine Korrektur eintritt, mit einem „correction Low“ (cL). Dieses kann natürlich höher liegen als der nach einem neuen Hoch zu setzende trailStop, weil weitere tiefere Tiefs eintreten können.

Hier nun die neue Fassung von trailTrend, sie trägt die Versionsbezeichnung „1.2, 14.6.2010“.

// stock-profi
// 20.11.2006
// ist am Anfang des Trades evtl. nicht aktiv, daher ist stopLoss als Ergänzung sinnvoll
// 14.6.2010: lH(lokales Hoch) statt nH in der Textanzeige, nH als Zusatztext,
// Bestimmung lokales Tief nicht mehr vom 1. Stab nach dem lokalen Hoch bis zum neuen Hoch,
// sondern vom lokalen Hoch bis zum neuen Hoch mit Verlaufsannahme beim ersten und letzten Stab
// Anzeige der Korrektur
Meta:
    Synopsis ("gibt bei long das letzte lokale Tief unabhängig von der Stärke bei einem neuen Hoch als TrailStopLevel an die StopEngine" ),
    Legend ("trTrend %p"),
    SubChart (False);
    
Inputs: //Formulierung nur für long, gilt für short sinngemäß
        // Definition der Korrektur
        correction (4.0, 0.0), // in vola zwischen localHigh und localLow, nur aktiv falls > 0
        volaLength (20, 1),
        sepBars (30, 0), // Anzahl Bars zwischen localHigh und Bar mit neuem High, nur aktiv falls > 0
        // sind beide aktiv, gilt oder - Verbindung
        showLocalHiLo (false), // zeigt lokale Highs
        showNewHiLo (false), // zeigt neue Highs
        showCorrection (false), // zeigt Korrektur nach einem lokalen High
        trailOn (true); // trailStop kann abgeschaltet werden


Und ein Beispiel:
DAX PERFORMANCE-INDEX
Bisher ist am durch den Pfeil gekennzeichneten Stab am 2.5.2010 ein neuer trailStop auf das Tief des Stabes gesetzt worden, der zum Ausstoppen am nächsten Stab führt. Dies war aber nicht korrekt, weil das Tief nach dem Hoch erreicht wurde. Und zwar nicht nur nach der Verlaufsannahme, sondern auch in der Realität, wie man am Tageschart nachvollziehen kann.
#250: 03.03.2010 16:50 stock-profi
Die um die Warnungen erweiterte stopEngine erhält eine neue Versionsbezeichnung, sie lautet:

Version 5.4, 1.3.2010

Um bestimmten Fehlern in Zukunft schneller auf die Schliche zu kommen, habe ich in alle stopLoss- und trail- Module eine Versionsangabe eingebaut.
Die Bezeichnung lautet derzeit in allen Modulen:

Version 1.1, 2.3.2010.

Man kann die Versionsbezeichnungen in der print-Ausgabe anzeigen, indem man in die Kommandozeile
debug::FromBar = 1;
eingibt.

Man erkennt dann auch, an welchen Stäben die Stopp- und trail-Module starten, wann die stopEngine startet und wann vollständige Synchronisation der Module hergestellt ist bzw. welche trades durch stopLoss bzw. trailstop noch nicht ausgestoppt werden können.
#249: 03.03.2010 16:33 stock-profi
Im folgenden Chart ist Anzahl Daten gleich 1000, der Chart beginnt am 23.3.2006.
DAX PERFORMANCE-INDEX
Der trailChandelier beginnt am 5.6.2006, der stopValue am 24.3.2006. Der Tag des ersten Einstiegs ist der 19.4.2006, der Tag des zweiten Einstiegs ist der 23.5.2006.

Der trailStop beginnt daher erst mit dem dritten Einstieg am 16.6.2006, für die ersten beiden Trades erscheinen die Warnungen:

SE noTrailStop 2006/04/19 00:00:00.000 .DAX Warnung3: trailStop wirkt nicht bei TradeNr 1
SE noTrailStop 2006/05/23 00:00:00.000 .DAX Warnung3: trailStop wirkt nicht bei TradeNr 2

Wenn ich keinen trailStop auf dem Chart habe, erscheint die Warnung3 bei jedem Trade. Wem das nicht recht ist, der löscht entweder die Formel
Debug::FromBar = 1;
oder setzt setTrail in der stopEngine auf nein.
#248: 03.03.2010 16:17 stock-profi
Im folgenden Chart ist Anzahl Daten gleich 1000, der Chart beginnt am 23.3.2006.
DAX PERFORMANCE-INDEX
Der trailChandelier beginnt am 24.3.2006, der stopValue am 19.4.2006, das ist auch der Tag des ersten Einstiegs.

Weil der stopValue nicht schon mindestens einen Tag vor dem Einstieg aktiv ist, kann der erste Trade nicht ausgestoppt werden.

Ich habe die stopEngine dahingehend erweitert, dass eine Warnung erscheint:

SE noStopLoss 2006/04/19 00:00:00.000 .DAX Warnung2: stopLoss wirkt nicht bei TradeNr 1

Ab dem zweiten Trade ist der stopLoss aktiv.

Wenn ich in stopValue den Input length auf 60 stelle, beginnt der stopValue am 19.6.2006, also nach dem dritten Trade. Der stopLoss wird dann erstmals beim 4. Trade wirksam, für die ersten drei Trades kommt die Warnung 2.

Wenn ich keinen stopLoss auf dem Chart habe, erscheint die Warnung2 bei jedem Trade. Wem das nicht recht ist, der löscht entweder die Formel
Debug::FromBar = 1;
Oder setzt setStop in der stopEngine auf nein.
#247: 03.03.2010 15:33 stock-profi
Die stopEngine beginnt an Stab 2 auf dem Chart. Technisch gesprochen ist die Bedingung currentBar = 1 an Stab 2 auf dem Chart erfüllt.

Ein Handelssystem kann schon an Stab 1 oder Stab 2 auf dem Chart beginnen. Hier ist ein Beispiel:

Equilla Skript "breakoutLongDis (Strategy)"

Mit dem Input i verstellt man den Beginn des Moduls.

Ein stopLoss-Modul oder ein trail – Modul kann ebenfalls an Stab 1 oder 2 beginnen, aber auch erst an Stab 30 auf dem Chart.

Natürlich ist die stopEngine auf diese Synchronisationsaufgaben vorbereitet und bearbeitet sie auch, soweit ich weiß, korrekt. :) Die stopEngine verarbeitet einen stopLoss oder einen trailStop nur dann, wenn dieser zu Beginn eines neuen Trades aktiv ist (d.h. die Bedingung currentBar = 1 erfüllt hat). Wenn der erste Bar im Trade auch ausgestoppt werden soll (der Input stopFirstBar in der stopEngine steht auf ja), muß das stopLoss - Modul einen Stab vor dem Beginn des Trades aktiv sein.
Der Beginn eines Trades wird von der stopEngine frühestens an Stab 3 auf dem Chart erkannt.

Die beschriebene Synchronisation der Module kann manchmal zu Irritationen führen.
DAX PERFORMANCE-INDEX
Der Chart beginnt am 21.3.2006, Anzahl Daten steht auf 1002. Hier passiert scheinbar gar nichts. Ein Fehler? Nein. Der Einstieg erfolgt an Stab 2 auf dem Chart, und an diesem Stab beginnen auch die zugeschalteten Module stopValue und trailChandelier. Da die stopEngine einen neuen Trade erst ab Stab 3 erkennt, können zu Beginn des Trades, also an Stab 2 auf dem Chart, die Module ihre Wirkung nicht entfalten. Einen neuen Tradebeginn gibt es aber nicht. Damit der Benutzer diese Situation in Zukunft leichter erkennt, habe ich für diesen Fall eine Warnung vorgesehen, die in der print-Ausgabe erscheint:

SE CB1 2006/03/22 00:00:00.000 .DAX Warnung1: stopEngine kann Trade, der an Bar 1 bzw. Bar 2 auf dem Chart beginnt, nicht ausstoppen

Der Benutzer muß in diesem Fall dafür sorgen, dass das erste Signal frühestens an Stab 3 auf dem Chart erscheint. In diesem Falle ist das ganz einfach möglich, indem man den Input i auf 1 stellt.
DAX PERFORMANCE-INDEX
Oder man erhöht die Anzahl Daten des Charts, in diesem Falle von 1002 auf 1003. Dann sieht es so aus:
DAX PERFORMANCE-INDEX
#246: 13.04.2009 17:26 stock-profi
Es folgt das Modul stopDisValue, mit dem man diskretionär einen Wert als stopLoss übergeben kann. Auch dieses Modul kann entweder stand alone oder nach einem anderen stopLossModul auf den Chart gezogen werden. Ebenso wie das Modul stopDisLevel kann es auch in einem Portfolio zum Einsatz gebracht werden.

Equilla Skript "stopDisValue (Strategy)"

Hier das Ergebnis bei einem stand alone Einsatz, wobei ich die stopEngine so eingestellt habe, dass sie am ersten Stab nicht ausstoppt. Deswegen ist das Datum des ersten Stabes im Trade einzustellen.
ALLIANZ SE VNA O.N. (3)
Selbstverständlich kann man auch ein Modul schreiben, bei dem man in einigen Trades einen level, in anderen Trades einen Wert vorgibt. Das sollte allerdings nach den letzten Beispielen für jedermann möglich sein. Wer es nicht machen will, zieht einfach stopDisLevel und stopDisValue auf den Chart.
#245: 13.04.2009 17:08 stock-profi
Hier ist jetzt ein Beispiel für einen diskretionären stopLevel:

Equilla Skript "stopDisLevel (Strategy)"

Das liefert im stand-alone Einsatz, also als einziges stopLoss-Modul, zusammen mit einem Keltner-Einstieg folgendes Ergebnis:
ALLIANZ SE VNA O.N. (2)
Man erkennt, dass nur an den gewünschten Terminen ein stopLoss gesetzt wird. Im September 2008 und im Januar 2009 finden Trades ohne stopLoss statt. Setzt man im Signal Prozessor „bearish“ auf ShortEntry, werden auch zwei shortTrades mit stopLossLevel versehen.

Zusammen mit dem Modul stopValue ergibt sich folgendes Ergebnis:
ALLIANZ SE VNA O.N. (1)
Im Normalfall wird hier das Modul stopValue mit einem Wert von 2 ATR zugrunde gelegt. Der Trader kann mit dem Modul stopDisLevel entscheiden, dass an einigen wenigen Trades stattdessen ein diskretionärer stopLoss gelten soll.

Man kann das Modul stopDisLevel auch zusammen mit anderen stopLossModulen, die mit Level arbeiten, einsetzen, z.B. mit stopChannel.

Wer das Modul stopDisLevel nutzen will, muß die neue stopEngine anfordern. Bitte nicht böse sein, wenn noch Fehler drin sein sollten. Es gibt so viele Fälle, dass ich aus Zeitgründen nicht alles testen kann.
#244: 13.04.2009 17:01 stock-profi
Verschiedentlich ist der Wunsch an mich herangetragen worden, einen diskretionären StopLoss zu realisieren.

Das hört sich sehr simpel an, hat aber doch zu kleinen Änderungen in der stopEngine geführt.

Ich habe es so realisiert, dass man den diskretionären stopLoss nicht bei jedem Trade einzugeben braucht, sondern nur bei Bedarf. Bisher nahm die stopEngine allerdings an, dass bei jedem Trade ein stopLoss vorlag.
Ferner habe ich vorgesehen, dass z.B. der stopValue bei Bedarf, also bei einzelnen Trades, durch einen diskretionären stopLossLevel überschrieben wird. Die stopEngine muß also in einigen Trades mit stopValue, in anderen mit stopLevel arbeiten, was bisher nicht möglich war, weil data1::stopMode in der stopEngine als konstant angenommen wurde.

Die Regeln für die neue stopEngine lauten jetzt folgendermaßen:

1. data1::stopMode kann an jedem Stab anders gesetzt werden:

0 oder „value“ bedeuten die Übergabe eines Wertes, der als höchster Verlust in Punkten pro Kontrakt akzeptiert wird, der Wert selbst wird wie bisher über data1::stopLossValue geliefert.
1 oder „level“ bedeuten die Übergabe von Werten, die als stopLossLevel angesehen werden. Erreichen die Kurse diesen Level, wird die Position ausgestoppt. Die Werte selbst werden wie bisher über die Variablen data1::stopLossLevelLong und data1::stopLossLevelShort übergeben.
Der Wert „none“ bedeutet, dass die stopEngine an diesem Stab keinen stopLoss setzt.

Nachdem die stopEngine den Wert von data1::stopMode an einem Stab ausgewertet hat, setzt sie ihn auf „none“. Dies hat zur Folge, dass ein stopLoss-Modul den Wert von data1::stopMode nur dann setzen muß, wenn an einem Stab ein stopLoss gewünscht wird. Da die bisherigen stopLoss-Module (level) data1::stopMode nur beim ersten Stab auf 1 gesetzt haben, musste ich sie geringfügig ändern.

2. Wie bisher nimmt die stopEngine die Existenz eines Stopp-Moduls an, sobald erstmalig eine der folgenden Variablen einen Wert größer Null hat: data1::stopLossValue, data1::stopLossLevelLong, data1::stopLossLevelShort. Sie setzt ferner wie bisher zusätzlich erst ab dem ersten Trade einen Stop, denn sonst könnte es sein, dass ein Trade beginnt und das stopLoss-Modul erst mitten im Trade. Deswegen kann der erste Trade nicht am ersten Stab ausgestoppt werden. Neu ist, dass die stopEngine nur dann einen stopLoss setzt, wenn data1::stopMode an diesem Stab entweder den Wert 0 bzw. „value“ oder den Wert 1 bzw. „level“ hat.

3. Steht in der stopEngine die Input-Variable stopFirstBar auf „wahr“, ist also auch der erste Stab eines Trades auszustoppen, sind die vorstehend beschriebenen Variablen am Stab vor dem Beginn des Trades zu setzen. Steht stopFirstBar auf „nein“, sind die Variablen am Stab des Beginns des Trades zu setzen.

Wer diese Regeln beachtet, kann eigene stopLoss-Module schreiben, die dann von der stopEngine verarbeitet werden. Die Zusammenarbeit mit den trail-Modulen bleibt unverändert.

Die neue stopEngine trägt die Versionsnummer 5.3.
#243: 02.12.2008 10:41 stock-profi
@KenParker (#242)

siehe #241
#242: 01.12.2008 21:32 KenParker
Vom Verfasser oder vom Besitzer der Diskussion gelöscht.
Seite 1 von 2612345