Jump to content






Photo
- - - - -

Chartpattern Description Language - CDL Part 2

Posted by Mythos , 29. August 2012 · 938 views

cdl evolution pattern
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, < 0 bedeutet C <= O , 0 bedeutet "colorblind" es ist dann also egal ob die Kerze schwarz oder weiß ist
# 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] < H[1]" und "H[1] < H[0]" abgebildet werden.

Parameter:

# Price1 - eine PriceID
# Price2 - eine PriceID
# minDiff - die minimale Differenz zwischen den Werten. Bei negativer Differenz gilt Price1 < Price2 + minDiff = Price2 - ABS(minDiff),  sonst 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... Posted Image ). Nächster Punkt ist die Implementierung. Bleibt also spannend, noch ist die Hoffnung auf den Gral nicht verloren ;)

  • 1



April 2021

M T W T F S S
   1234
567891011
12131415 16 1718
19202122232425
2627282930  

Recent Comments

Recent Entries

2 user(s) viewing

0 members, 2 guests, 0 anonymous users

Categories

Latest Visitors

  • Photo
    eurix
    14. Apr 2017 - 21:50 Uhr
  • Photo
    chimbonda
    03. Jul 2016 - 11:49 Uhr
  • Photo
    tompaul
    21. May 2016 - 16:37 Uhr
  • Photo
    fatlemming
    24. Jan 2016 - 17:41 Uhr
  • Photo
    compulsorytrading
    11. Dec 2014 - 09:33 Uhr