Jump to content
Tom Next - Daytrading Community
  • entries
    19
  • comments
    44
  • views
    36,436

Chartpattern Description Language - CDL Part 2


Mythos

1,436 views

Weiter gehts. In Teil 1 hab ich die Grundstruktur und die Targets beschrieben. Jetzt kommen die eigentlichen Regeln der CDL:

 

Ein Chartpattern soll wie gesagt durch eine Anzahl an Regeln beschrieben werden. Für den Anfang werd ich mich auf 2 Typen von Regeln beschränken und mal hoffen damit möglichst viel abzudecken.

 

Die Regeln

 

RULE_BAR_FORM

Diese Regel definiert das Aussehen eines bestimmten Bars im Pattern. Damit werden bei Patterns mit nur 1 Bar zB typische Candle-patterns abgedeckt (Hammer etc.). Bei Patterns mit mehreren Bars kann man dann aber auch so Sachen wie die "3 weißen Soldaten" (ich glaub das heißt so) abbilden (einfach 3 dieser Regeln, einen pro Bar).

 

Parameter:

 

# BarOffset: welcher Bar im Pattern gemeint ist 0 ... der aktuellste Bar, 1... einer davor etc.

# Direction: > 0 bedeutet C >= O,

# isRelativ: wenn > 0 sind die folgenden Werte in Prozent von H-L zu werten (bzw. in Anteilen, vor Abgleich werden sie also normiert das die Summe 100% ergibt). Ansonsten in Pips

# sizeCandle: Größe des Kerzenkörpers = ABS(C-O)

# upperDocht: = H-MAX(O,C)

# lowerDocht: = MIN(O,C)-L

 

RULE_VALUE_RELATION

Mit dieser Rule soll alles abgebildet werden können was die Relation zwischen 2 Werten (definiert über PriceID) innerhalb des Patterns definiert. zB "steigende Highs über 3 Bars" kann mit den Regeln "H[2]

 

Parameter:

 

# Price1 - eine PriceID

# Price2 - eine PriceID

# minDiff - die minimale Differenz zwischen den Werten. Bei negativer Differenz gilt Price1 = Price2 + minDiff

# isRelative: wenn > 0 ist die minDiff in Prozent von H-L vom Bar von Price1

 

Mutation und Kombination

Der Mutationsteil ist recht einfach: jeder Parameter hat bei jedem Wert eine "sinnvolle" Bedeutung, somit kann jeder Parameter "beliebig" mutiert und verändert werden.

Einzig bei PriceIDs werde ich es so einschränken das nur entweder der BarsBack-Teil oder der Identifier mutiert wird.

Außerdem können natürlich zufällig neue Regeln dazukommen.

 

Bei der Kombination werde ich nur die Vermischung von gleichen Regel-typen zulassen.

Bei PriceIDs gibt es entweder eine Vermischung der BarsBack Komponente oder einer der zwei Identifier wird gewählt.

Alle anderen Parameter werden als zufällig gewichteter Mittelwert der Eltern gewählt.

Um das Ganze ein bissl geordnet zu halten, werden die Regeln immer sortiert gespeichert. Zurest RULE_BAR_FORMs und dann RULE_VALUE_RELATIONs. Und hier auch nach Offset bzw. Price1 sortiert. Sprich wenn möglich werden "gleiche" Regeln (zB Barform des 2. Bars) miteinander kombiniert. Gibt es eine Regel nur in einem Elternpattern, wird zufällig entschieden ob sie übernommen wird oder nicht und ggf. mutiert.

 

Die Kombination der Targets ist etwas schwerer. Da jedes Pattern nur ein Target haben kann, wird bei Patterns mit unterschiedlichen Targettypen eines der beiden gewählt. Dieses Eltern-pattern hat dann ein stärkeres Gewicht bei der Regel-kombination (damit die Regeln zum Target passen, bzw. weil sich dessen Gene beim Target auch schon "durchgesetzt" haben ;)

 

Redundanz

Auf diese Weise (vor allem durch Mutation) kann es natürlich passieren das es eine Regel mehrfach (oder mehrfach sehr ähnlich) gibt. Das ist durchaus gewollt und ist auch in unserer DNS so gehalten. Wichtige Bausteine sind immer wieder beschrieben, verändert sich eine der vielen Beschreibungen zu sehr, wird sie von einer der anderen einfach überschrieben.

In unserem Fall wird nichts überschrieben, aber wenn eine Regel "wichtig ist" / oft vorkommt kann diese damit nicht so ausradiert werden. Bzw. es überlebt jenes Pattern lange, wo diese Regel öfter vorkommt und die damit nicht so anfällig für Mutation der "wichtigen" Regeln ist.

 

Matching eines Patterns

Was noch fehlt ist die Entscheidung ob ein Pattern matcht (und damit das Target überprüft werden muss).

Zuerst wird jede Regeln einzeln überprüft und eine Übereinstimmungsquote in Prozent berechnet.

Bei ValueRelation wird es einen leicht fließenden Übergang beim Schwellwert geben.

Bei BarForm gibt es diesen Übergang für jeden Wert wobei die Direction stärker gewichtet ist. Die Quote für ein BarForm ist das gewichtete Mittel von dessen Einzelquoten.

 

Dann wird der Mittelwert aus diesen Quoten berechnet. Ist die resultierende Gesamtquote größer als ein Schwellwert, "matcht" das Pattern.

 

 

Jo.. damit wär glaub ich mal die Version 1.0 der CDL beschrieben (Beschreibung einer Description... lines.gif ). Nächster Punkt ist die Implementierung. Bleibt also spannend, noch ist die Hoffnung auf den Gral nicht verloren ;)

0 Comments


Recommended Comments

There are no comments to display.

×
×
  • Create New...