Jump to content
Tom Next - Daytrading Community

Search the Community

Showing results for tags 'pattern'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Investmentideas
    • Trading + Co.
  • Suspicious Minds
    • fabian.john@gmail.comMr. Fraud & Ms. Scam
    • Red Flag
  • Off-Topic
    • Best Off
  • Trading Desk
    • Contract for Difference
    • Bitcoin
    • Financial Spread Betting
    • Futures & Optionen
    • Finanzwetten · Digitals
  • Behind the scences
    • Public Relations
    • Ich hab da mal 'ne Frage...
    • Technical Support
    • Think Tank
  • Programmierbare Handelsplattformen & Chartsoftware
    • Metatrader
    • MultiCharts
    • Ninjatrader
    • Amibroker
    • Agena Trader
    • JForex
    • Maran-Trader
    • Strategy Trader
    • Informations- und Analyseprogramme
  • Handelsansätze und Tradingstrategien im Praxistest
    • Trading Setups
  • Technische Analyse
    • Charting und Technische Analyse
    • Science
  • Social Investment Networks
    • Social Trading
  • Broker
    • MB Trading
    • Interactive Brokers
  • High Frequency / Algo Trading
    • Black Box
  • Exotics
    • Trading Sports
    • Event Futures
  • Programmierung
    • Programmiersprachen
  • tom-next.com · international
    • International Community
  • Tech Zone
    • Helpdesk
    • IT, Internet, Software

Blogs

  • Call the Shots
  • siscop's Blog
  • First-Level-Trading
  • Ecart's Blog
  • DarthTrader's Blog
  • Henrik's Blog
  • røøt66
  • stefan's Blog
  • tinozi's Blog
  • - Maerl Brontius -
  • Rumpel's Blog
  • Proudroses' Blog
  • Vola's Blog
  • OS_Trading
  • Mako's Alte Zeiten Blog
  • Maerl Brontius' Blog
  • Elad Nava's Blog
  • Corporate Blog
  • Mythos Down Under
  • 17:33h
  • PermissionControll's Blog
  • tester2's Blog
  • IPS' Blog
  • Exchange - Developement
  • Ein Externer Blog
  • MetaTraders
  • Der TEFEx Millionär
  • Lobo's Schnipsel Blog
  • Betfair-Review
  • My-privatbroker
  • Jimboo's Blog
  • KI vs. Evolution
  • Let the machines trade

Categories

  • MT4 Commmunity
    • Community Projekte
    • Einzelprojekte
    • Tickdaten
    • Misc (internal stuff)
  • MT4 Codes
    • A-Z
  • e-Book Exchange
    • .pdf *mixed*
    • Technische Analyse
    • Trading Know How
    • Metatrader/MQL
    • FX Know How
  • Contract for Difference
  • Miscellaneous
  • Allgemein/ Unsortiert
  • Manuals & User Guides
  • Finanzmarktaufsicht
  • Community Projekte
  • Ninjatrader

Calendars

  • Finanzkalender
  • Community Kalender

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Wohnsitz


Interessen


Name des Mitglieds

Found 4 results

  1. Eigentlich wollte ich gerade mit der Implementierung anfangen, da hab ich gemerkt das ich das Bewertungssystem noch gar nicht beschrieben habe. Im letzten Eintrag hab ich gerade noch beschrieben wann ein Chartpattern auf den aktuellen Kursverlauf matcht. Aber für die Evolution dürfen sich ja nur die "erfolgreichsten" fortpflanzen. Also folgender Plan für die "natürliche Auslese" : Jede Generation wird natürlich neu bewertet, es bringt also nix wenn die Eltern erfolgreich waren. Jedes Pattern einer Generation wird auf X (vermutlich 5000) Bars getestet, wenn es matcht und das Target erfüllt bekommt es Bewertung +1. Gleichzeitig wird mitgezählt wie oft es gematcht hat. Die Gesamtbewertung berechnet sich dann folgend: Ist die Anzahl der matches > X/10: Gesamtbewertung = Bewertung/Anzahl. Ist die Anzahl Gesamtbewertung= Bewertung/Anzahl* (Anzahl/(X/10)) = 10*Bewertung/X Sprich wenn es weniger als in 10% der Fälle matcht, wird die relative Bewertung linear reduziert bis 0. So, jetzt kann die Implementierung aber endgültig starten.
  2. 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... ). Nächster Punkt ist die Implementierung. Bleibt also spannend, noch ist die Hoffnung auf den Gral nicht verloren ;)
  3. Dann legen wir mal mit dem 2. Teil des Projektes los: Die Evolution der Pattern-Recognition. (Der Titel ist doch schon mal schön ;) Die Idee dahinter Es wird wie gesagt ein Evolutionsalgorithmus. Entwickelt (Evolutioniert klingt komisch) werden Chartpatterns die eine statistisch signifikante Prognose geben. Hierbei will ich mich gar nicht weiter einschränken was die Chartpatterns angeht. Zu Beginn werden es sicher nur simple Patterns, mit der Zeit soll aber deren Komplexität auch ausgebaut werden (soweit es MQL halt zulässt). Chart-Pattern Description Language Um überhaupt Evolution betreiben zu können, benötigt es eine Definition der "Gene". Bzw. eine Beschreibung welches Gen was bewirkt. Anders gesagt muss es gelingen "beliebige" Chart-Patterns mit einer (möglichst kleinen) Menge an Parametern eindeutig zu beschreiben. Ich nenn diese Beschreibung jetzt einfach mal Chart-Pattern Description Language (kurz CDL). Da ich sowas selber noch nie gemacht habe, kann es leicht sein das die CDL sich im Laufe der Entwicklung noch gravierend ändert, nur als Vorwarnung. Zunächst wird die CDL aus einer (beliebigen) Anzahl an Regeln bestehen. Von den Regeln wird es mehrere Typen geben. zB "Bar X hat folgende Form" oder "Wert von Bar X steht in diesem Verhältnis zu Wert von Bar Y". Über die CDL werde ich noch einen eigenen Eintrag schreiben. Die Bewertungsfunktion Jedes Pattern bekommt eine "Targetfunktion". Sprich es muss nicht jedes Pattern das Close des nächsten Bars vorhersagen. Auch hier wird es wieder unterschiedliche Typen geben. zB "Wenn beim nächsten Bar Preis X überstiegen wird, steigt der Preis um Y weiter", oder eben das klassische "Der nächste Close ist mind. X über dem aktuellen". Weiters gibt es für jede Regel in der CDL eine "Ähnlichkeitsfunktion" die entscheidet wie sehr das aktuelle Chartbild diese Regel erfüllt. Ist die gesamte Ähnlichkeit des Patterns unter dem Schwellwert, so "muss" die Aussage der Targetfunktion zutreffen. Bewertet wird wie oft die Targetfunktion zutrifft relativ zur Anzahl wie oft das Pattern gepasst hat. Matcht das Pattern zu selten (zB Die Evolution Erfolgreiche Patterns werden dann miteinander kombiniert: Sprich es wird eine Teilmenge der Regeln der beiden "Eltern" übernommen. Wenn beide Eltern eine Regel enthalten, so kommt sie "sehr wahrscheinlich" auch ins neue Pattern und die Parameter der Regel werden "kombiniert". Zusätzlich gibt es natürlich Mutationen, sprich es kommen teils zufällig neue Regel dazu. Bzw. Regeln ändern ihre Parameter teils zufällig. Die Implementierung Wenn sich jetzt jemand fragt wie zum Teufel ich das in MQL bauen will, da hab ich ehrlich gesagt selber noch keine Ahnung. Das Projekt schreit ja regelrecht nach Objektorientierung. Aber zumindest in der ersten Version wird sich schon ein Weg finden. Ggf. muss ich halt auf eine C++ dll ausweichen, das will ich aber so gut es geht vermeiden. als dann wiedermal thx for reading ;)
  4. Wie versprochen Version 0.1 der CDL aka "Was ich mir grad vorm Fernseher zusammengereimt habe" Anforderungen Die CDL soll wie gesagt die Möglichkeit liefern ein Chartpattern möglichst genau zu beschreiben und dabei einem möglichst allgemeinem Muster folgen. Jede Pattern-Beschreibung soll aus ein Reihe eigenständiger Definition/Regeln bestehen, die beliebig kombiniert und ersetzt werden können. Es sollte möglich sein Regeln miteinander zu vergleichen um "ähnliche" Regeln zu vermischen Jede Regel muss eine Möglichkeit der Kombination mit "ähnlichen" Regeln haben, sowie Möglichkeiten der "Mutation" (zufällige Veränderung der Regel sodass sie (meistens) sinnvoll bleibt). Zugegeben, diese Anforderungen sind bereits mit einer Idee für die CDL geschrieben. Trotzdem spiegeln sie glaub ich die Grundanforderungen recht gut wider. Grundaufbau der CDL Jedes Chartpattern wird beschrieben von einer Reihe von Regeln und einem Target. Repräsentiert werden diese Regeln und das Target je als ein Array. Dadurch ist sogar eine "effiziente" Verwaltung in MT möglich. Der Einfachheitshalber besteht jedes Pattern aus maximal 50 Regeln und jede Regel wird mit maximal 10 (muss ggf. erweitert werden) Werten definiert. Das Target wird ebenfalls mit maximal 10 Werten definiert. Es gibt verschiedene Typen von Regeln und Targets. Der erste definierende Wert jeder Regel/Target bestimmt dessen Typ und entsprechend werden die darauffolgenden Werte interpretiert. Ein Chartpattern ist also mit einem 2D-Array nach folgendem Muster definiert: In Zeile 1 sind "technische" Werte des Patterns gespeichert (Anzahl der verwendeten Regeln, maxBarsBack etc), also Werte die nicht zu den Genen des Patterns zählen sondern für die konkrete Implementierung notwendig sind, eine Art "Header". pattern[1][0-9] enthält das Target. pattern[1][0] ist der Typ des Targets, die restlichen Werte in dieser Zeile sind vom Typ des Targets abhängig. pattern[2][0-9] enthält die erste Regel des Patterns. Wiederum enthält pattern[2][0] den Typ, der Rest ist abhängig vom Typ. pattern[3][0-9] enthält die zweite Regel und so weiter PriceID Da innerhalb der Regeln immer wieder auf verschiedene Preise referenziert wird, müssen diese codiert werden. Dies erfolgt mit den PriceIDs nach dieser Form: X wobei X aus 0-9 ist und angibt welcher Wert des entsprechenden Bars verwendet wird. 0 - Open, 1-High, 2-Low, 3-Close, 4-(H+L)/2, 5- (H+L+C)/3, 6- HighestHigh im Pattern, 7-LowestLow im Pattern wird also auf das High des aktuellen Bars referenziert ist die PriceID 1, High des letzten Bars: 11, Close des vorletzten Bars: 23, Open des 10. letzten Bars: 100 etc. Die Targets Zu Beginn gibt es mal 3 Typen von Targets: TARGET_PREDICTION Bedeutet eine Vorhersage des Close des nächsten Bars, jedoch nicht punktgenau sondern nur die Richtung und minimale Bewegung. Parameter: # Richtung +1 für rauf, -1 für runter # min Bewegung # isRelative: minimale Bewegung ist absolute oder % des aktuellen Bars Das Target ist erfüllt wenn der Close des nächsten Bars die entsprechende Entfernung in der gegeben Richtung überschreitet. (Oder sollte man hier besser High/Low nehmen, also die maximale Bewegung im nächsten Bar?) TARGET_BREAKOUT_MOVE Dieses Target ist gedacht für Patterns wie Keile. Wenn die obere Schwelle durchbrochen wird, muss eine starke Bewegung nach oben folgen, wird die untere durchbrochen eine Bewegung nach unten. Parameter: # Schwelle Long - eine PriceID # Schwelle Short - eine PriceID # min Bewegung bei Durchbruch # isRelative (wie oben) Das Target ist erfüllt wenn der Bar nach dem Pattern eine (genau eine?) Schwelle durchbricht und die mindestens die min Bewegung weiterläuft oder keine der beiden Schwellen durchbricht (dann zählt das Pattern als nicht gematcht, aber nicht als nicht erfüllt). TARGET_BREAKTHROUGH_MOVE Der klassische Durchbruch durch einen Widerstand. Erkannt wird eine Schwelle bei dessen Durchbruch der Kurs deutlich weiter in diese Richtung marschiert. Parameter: # Richtung +1 oder -1 # Schwelle - eine PriceID # min Bewegung bei Durchbruch # isRelative (wie oben) Das Target ist erfüllt wenn der Bar nach dem Pattern die Schwelle durchbricht und mindestens die min Bewegung weiterläuft oder die Schwelle nicht durchbricht (dann zählt das Pattern als nicht gematcht, aber nicht als nicht erfüllt). Da das schon ein recht langer Eintrag ist, mach ich hier mal Pause. Weiter gehts die nächsten Tage in Teil 2.
×
×
  • Create New...