Jump to content
Tom Next - Daytrading Community

Search the Community

Showing results for tags 'cdl'.

  • 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 5 results

  1. Da bin ich wieder. Wie zu erwarten war geht nach Behebung (hoffentlich) aller Denk- und Implementierungsfehler die Trefferquote nicht mehr entsprechend nach oben. Also heißt es die Logiken überarbeiten. Einerseits hab ich eine Sinnhaftigkeitsfilterung eingebaut. Damit es nicht passieren kann das zb eine Regel den gleichen Wert mit sich selbst vergleichen will etc. Andererseits überlege ich grade ob der Matchingalgo wirklich so sinnvoll ist. Es gibt derzeit Regeln die aus mehreren Teilkriterien bestehen und ein Pattern besteht aus mehreren Regeln. Wie sollte man diese am besten kombinieren? Methoden die mir derzeit einfallen (und halbwegs sinn machen): Mittelwert: Jedes Kriterium erhält ja einen Wert zwischen 0 und 100 wie gut es erfüllt ist. Der gemeinsame Wert ist der Mittelwert der Einzelwerte. Das würde bedeuten das ein einzelnes nicht matchendes Kriterium überstimmt werden kann (9*100 + 0)/10 = 90%. Aber von der Logik her matched ein Pattern nur wenn alle Regeln erfüllt sind oder? Multiplikation: Die prozentuellen Matches werden multipliziert. Damit sorgt ein einziges nichterfülltes für ein komplettes 0%. Aber gleichzeitig kann das Ergebniss auch schnell schlechter als das schlechteste Einzelmatching sein (0.9*0.9= 0.81). Bin mir grad nit sicher ob das so gut ist oder nicht Minimum: Man nimmt einfach das Minimum der Einzelwerte. Damit ignoriert man natürlich alle anderen Ergebnisse, was jetzt aber nicht schlecht sein muss. Ich glaub ich werds jetzt mal einstellbar implementieren und ein bissl damit experimentieren. Allgemein seh ich gerade ein bissl ein Problem darin, wie der Algo "intelligent" lernen kann. Das mutieren und vermischen von Patterns klingt in der Theorie gut, aber ist es mehr als "raten"? Möglicherweise bau ich noch was ein das jede Regel sich merkt wie oft sie gematcht hat und dementsprechend bei der Auswahl behandelt wird. zB Regeln die selten/nie matchen, werden wahrscheinlicher nicht übernommen. schau ma mal...
  2. Hallo Leute, zuerstmal sorry für die lange Wartezeit. Die letzten Wochen waren bei mir beruflich sehr stressig wodurch die Motiviation und Energie für alle anderen Projekte leider entsprechend gelitten hat. Zusätzlich muss ich sagen das die Umsetzung der CDL doch etwas komplexer war als erhofft, aber alles der Reihe nach: Die Implementierung Wie der Titel schon sagt steht Version 0.2 der CDL, wobei ich immer schlecht in Versionsnummern bin. Eigentlich stehts kurz vor Version 1.0 . Von den Funktionen her ist jetzt alles drin was in den vorigen Beiträgen beschrieben wurde. Umgesetzt hab ichs auch ziemlich genau wie geplant. Da es in MT scheinbar keine Möglichkeit gibt ein Teilarray als Parameter zu übergeben (also zB array[2] von einem 2-dimensionalen Array) wars teils etwas komplizierter zu schreiben, aber mei. Es geht ja erstmal nur um einen Proof-of-Concept. noch ein paar technische Details: Um die Lesbarkeit ein wenig aufrecht zu erhalten, hab ich die Lib inzwischen in mehrere mqh aufgeteilt die jedoch nur zusammen funktionieren. Aber dadurch erspart man sich das ewige Suchen und Scrollen im großen File. Es gibt derzeit 3 mqh und die lib selbst, jedes File ca 300 Zeilen. Also für ein "richtiges" Softwareprojekt nicht erwähnenswert. (Ich frag mich grad wieso ich solang dafür gebraucht hab ) Funktionsweise und Testablauf Die Grundfunktionalität ist wie gesagt ziemlich genau wie geplant. Zusätzlich hab ich noch speichern der Patterns in Files hinzugefügt: Jedes Pattern erhält sein eigenes File. Der Dateiname setzt sich aus der Trefferquote des Patterns und der ID zusammen. Die Trefferquote hab ich dazugetan damit man schnell die guten Patterns analysieren kann. Zusätzlich gibts ein File mit einer Liste der derzeit aktiven Patterns (inkl. Trefferquote damit man eindeutig das File findet). Im Moment wird die Dateistruktur aber nur zur manuellen Analyse verwendet. Ursprünglich wollte ich ja mit einer Menge von "klassischen" Chartpattern starten und diese Evolutionieren lassen, aber aus Faulheit geh ich derzeit her und erzeuge einfach zufällig 50 Patterns als Start. Pro Generation werden alle mit einer Trefferquote in den oberen 20% zur "Fortpflanzung" verwendet. Außerdem werden (im Gegensatz zum Plan) 30% der alten guten (also obere 20%) Patterns wiederverwendet. Aus dem einfachen Grund weil sonst gute Patterns in der Evolution verloren gehen könnten (und auch wirklich verloren gingen). Wenn die beste Trefferquote erste Ergebnisse Gehts rein nach den Werten bin ich jetzt natürlich schon lange reich Gestern Abend hab ich die ersten Evolutionen laufen lassen und bereits nach ein paar Generationen ist die Trefferquote von 0 auf 99% gestiegen. (bei 5000 Bars im Test) und das unabhängig vom TF. Meine anfängliche Skepsis war leider berechtigt: Bei der Entwicklung haben sich ein paar "Denkfehler" eingeschlichen. Es sind einfach nicht alle Targetfunktionen sinnvoll, hier eine Liste der bisher erkannten Denkfehler: Breakout/Breakthrough: Die minimale Bewegung nach dem Durchbruch darf natürlich nicht negativ sein. Das Target "Wenn das High > 10 ist, dann muss auch High > 10-2=8 sein" ist zwar immer erfüllt, bringt aber in der Tradingpraxis nicht sehr viel Die Schwelle beim Breakout/Breakthrough darf erst inbar durchschritten werden, sprich im Longfall muss gelten Open Low[0] => High[-1] > Low[0]+X" sehr häufig stimmt... Ein Breakout-Target bringt halt nur was, wenn man auch an der Schwelle einsteigen kann... Die minimale Bewegung muss größer als der Spread sein. Es bring nichts wenn ein Breakout passiert und der Kurs mindestens 1 Pip weiterläuft. Das Target ist zwar meist erfüllt, aber im Tradingalltag nicht profitabel Relative Bewegungen sind mit Vorsicht zu genießen. Gleiche Begründung wie beim Spread. Im M1 Chart hilft dir eine Bewegung von 5% vom Vorbar nicht wirklich was, das sind dann immer noch nur ein paar Pips. Um diese Situationen zu verhindern, hab ich Targetconstraints eingeführt. Nach Mutation und Paarung werden die Patterns auf diese Constraints zurechtgestutzt. also zB wird das "isRelative" Flag bei TF 0 gestutzt etc. Zusätzlich hab ich in der Targetauswertung den Spread miteinkalkuliert. Mit diesen Verbesserungen läuft jetzt eine neue Simulation. Im Daily sind wir bereits nach 30 Generationen auf > 90% Trefferquote, H1 auf 52%, M1 steht nach 200 Generationen immer noch bei 6 % und M15 hat erst 3 Generationen durch ;) Noch was technisches zu den Simulationen: Da ich hier keine Backtests mache sondern rein die Generationen in einem Skript laufen lasse, kann ich in einer MT Instanz das Skript auf mehreren Charts/TFs laufen lassen wodurch ich brav alle Kerne belasten kann :D Soweit mal der Zwischenbericht. Mal sehen wieviele Denkfehler und Stolpersteine ich heute noch finde... Freu mich wie immer auf Kommentare und Anregungen. Thx for reading
  3. 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.
  4. 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 ;)
  5. 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...