Mythos

Der Vorteil beim verprügeln mit einem MacBook: er hat auch gleich noch ein paar Brandwunden dazu...

Naja, bei dem Experiment gehts in erster Linie um den Versuch eben nicht vorzugeben "was" das NN lernen soll. Sprich ich will ihm nicht vorgeben woran ich ein Pattern festmache etc. Die Einschränkung auf Rauf/Nichtrauf trainiert derzeit. Bis jetzt mit gleich geringem Erfolg. Derzeit sind die Inputs alle relativ, genauso wie die wenigen verwendeten Indikatorwerte.

Sorry aber das is so aufgelegt: Welche Funktion haben denn die 8 svchost.exe die du offen hast? (Nicht bös gemeint, wie gesagt SCNR) Da geb ich dir Recht. Die normale Google-Websuche sollte aber auch keine Updatefunktion haben, ist ja kein lokales Programm. Also welches Programm von goolge will sich da bei dir updaten und warum hast du das noch? An sich bin ich ja bei dir bzgl. Kontrolle über den Rechner. Aber in dem Moment wo du ein Programm installierst gibst du einen Teil der Kontrolle her. Aber wenn man den Schritt macht und ein Programm zulässt, gibt es aus meiner Sicht defakto keine Gründe warum man außerhalb der vorgesehen Konfigurationsmöglichkeiten in dem Programm (und dem Komplex darum) herumpfuscht. Damit holt man sich Instabilität und Probleme ins Haus die meist leicht zu vermeiden sind. Aber wie gesagt nur meine Meinung. Ich hab auch bei vielen Programmen die Autoupdates auf "immer nachfragen" und durch die Firewall darf nur nach Hause telefonieren wer einen guten Grund hat ;)

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 ;)

Wie gesagt, es kann sehr leicht sein das es ein Repräsentationsproblem ist. Bzw. ist die Frage "Wie ist die richtige Repräsentation für ein NN?" noch weit weg von beantwortet. Bin für Vorschläge jederzeit offen.

blöde Frage: wieso sollte man eine Updatefunktion deaktivieren wollen? Updates sind dazu da sicherheitslücken und bugs zu schließen, bzw. das Programm allgemein besser zu machen...

@whipsaw: kann sein, kann nicht sein. Es war auf jeden Fall eine Teilmenge aus Opera, Software, Vorschau->Ändern->bestätigen,Internetconnection etc. Ich würde jetzt erstmal nicht sofort der Software die Schuld geben...

Wie die Outputs zu interpretieren sind ist mir halbwegs klar. Die Frage die bleibt: Auf was trainiere ich? Wenn ich trainingsdaten habe, die zu 60% "falsch" sind (weil sie sagen das NN sollte "rauf" signalisieren obwohl es hier gar nichts lernen kann), wie soll es dann sinnvoll lernen? Die Links schau ich mir dann am Abend an, muss jetzt ins Büro.

Genau das mache ich ja derzeit. Aber die bisherigen Ergebnisse lassen vermuten das es eben zu schwer zu sein scheint. An sich wäre es genau der Plan das Netz alles selber lernen zu lassen. Aber das Problem sind glaub ich die verrauschten Daten. Es gibt kein Pattern das immer stimmt. Vor allem weil die "nicht Aussagekräftigen Patterns" es glaub ich ziemlich vermasseln. Nehmen wir mal an es gibt ein Superpattern, wos mit 100% danach rauf geht. Selbst wenn das Netz dieses Pattern erkennt und zu 100% richtig prognostiziert, wenn das Pattern zB nur in 10% der Fälle auftritt (was schon viel wäre). Was prognostiziert das Netz in den restlichen 90%? Wenn es "flat" prognostiziert, ist das falsch, weil wir (da wir nicht wissen an welchen Bars der Output wichtig ist) für jeden Bar die Klassifizierung "rauf", "runter" oder "flat" machen. Wenn der Kurs also in 30% rauf, in 30% runter und 30% flat geht (also die 90% aufgeteilt), wird das Netz (da es die 90% nicht prognostizieren kann) immer mind. 60% fehlerquote haben. Und das obwohl es ein superpattern gelernt hat mit dem man reich werden würde. Wenn man wüsste wann es das Pattern erkannt hat, und wann es raten muss weil es "halt irgendwas sagen muss". Bei der Bilderkennung ist es leichter. Da gibt es eben nur "richtiges Bild" oder "falsches Bild". Falls dir eine Variante einfällt wie man ein solches Superpattern per NN lernen kann ohne 60% Fehlerquote zu erhalten: ich freu mich über Ideen ;)

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.

Naja bleibt die Frage was er dann lernen soll. Bei Bilderkennung ist es einfach. Da gibt es die Muster im Bild die erkannt werden und aus. Bei Kursverläufen ist es schwieriger weil zweischichtig: 1. Schicht/Frage: Welche Kursmuster haben danach einen statistisch signifikant prognostizierbaren Verlauf? Sprich nach welchen Patterns geht es rauf/runter? 2. Schicht/Frage: Möglichst fehlerfreie Erkennung dieser Muster. Ist Frage 1 geklärt hat man nur mehr ein klassisches Problem aus der Mustererkennung und ein NN läuft ohne Probleme. Aber genau Frage 1 ist ja der schwierige Teil. Ich befürchte das einerseits Frage 1 aber vor allem die Kombination zu "schwer" für ein NN ist. Man muss die Fragen also vermutlich doch getrennt behandeln. Bzgl. Encoding der Inputs: Ja das ist ein großes Problem, aber hier gehts auch wieder um Frage 1: Was ist sinnvoller: Repräsentation relativ zur ATR, in absoluten Pips, in % etc?

Wenns ok is, lass ich es stehen. Vielleicht hilfts wem anderen auch noch. Nochmal zum Verständnis: Das Problem an der Sache ist die Variable Größe der "hinteren" Dimensionen. Wenn ich es als "wirkliches" zweidimensionales Array machen würde. Müsste ich die 2 Dimension auf eine fixe Größe einstellen. Die ist dann entweder immer viel zu groß, oder schnell mal zu klein. Oder wie im aktuellen Fall: der erste Layer hat 500 Neuronen, der zweite 32, der dritte 3. Dann müsste das Array double[][500] sein, und man verbraucht unnötig Speicher (und womöglich auch Performance). Wie ich es gelöst hab, nochmal (hoffentlich) anschaulicher: Mit dem alten Beispiel: 3 Layer, erster Layer 5, zweiter 3, dritter 2 Neuronen. Das Array sieht dann so aus: "transferId[x][y]" bezeichnet die Id für Neuron y auf Layer x: { transferId[0][0],transferId[0][1],transferId[0][2],transferId[0][3],transferId[0][4], transferId[1][0],transferId[1][1],transferId[1][2], transferId[2][0],transferId[2][1] } transferId[1][0] liegt also bei Offset 5 ... Anzahl Neuronen am 1. Layer transferId[2][0] liegt bei Offset 5+3= 8 ... Anzahl Neuronen am 1. und 2. Layer HTH

Geclusterte Inputregionen sind keine blöde Idee. Aber ich hab immer mehr das Gefühl, dass das Netz nicht wirklich von den reinen Daten lernen kann. bzgl. Overfitting: Mit 5 Schichten hat es eben nicht gefittet sondern die Inputs schlicht ignoriert. Die ersten Schichten bekamen Gewichte um 0 und dann wurde mit dem Bias ein konstanter Output erzeugt. Das 5 Schichten extrem viel sind ist mir klar, ich wollts nur mal testen und war eben überrascht das es nicht fittet.

ja da scheint beim speichern was komplett durcheinander gewürfelt zu sein. Ich hab probiert den Text so gut es geht wiederherzustellen. Is nur schwer sich zu erinnern was man gestern geschrieben hat ;) Ja, die starke Vereinfachung wird auf jeden Fall nötig bzw. hab ich schon eine Idee wie ich das ganze angehen werde.

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 ;)

Wie versprochen hier ein bissl was grundlegendes zu Evolutionsalgorithmen. Gleich vorweg: Ich hab keine "Ausbildung" in dem Bereich. Alles was ich hier schreibe hab ich mir selbst erarbeitet. Es kann also leicht sein das meine Definitionen und Vorgehensweisen von den "offiziellen" abweichen. Das hier ist also die "Evolutionstheorie von mythos" Evolution at its best Wenn man Evolutionsalgorithmen verstehen will, muss man zuerst die Evolution als solches verstehen. Jeder hat den Begriff schon gehört, aber ich bin mir nicht sicher ob jeder weiß wie die Evolution wirklich funktioniert. Evolution basiert auf 2 Grundpfeilern: Überproduktion und natürliche Auslese Überproduktion Betrachtet man rein die "Geburtenraten" in der Natur, so gäbe es ein derart massives Wachstum der Populationen, das in wenigen Generationen die Erde zu klein wäre. (Sehen wir ja mit den Menschen zurzeit). Es kommen also viel mehr Exemplare einer Spezies auf die Welt, als "nötig" wären. natürliche Auslese Die "Evolution" ist kein hochintelligenter Apparat, der die Gene einer Spezies analysiert und entsprechend verbessert. Wenn ein neues Exemplar der Spezies gezeugt wird, setzen sich die Gene beider Seiten nicht zusammen und diskutieren welches das bessere ist. Die Gene der beiden Eltern werden einfach "zufällig" gemischt. Manche mutieren sogar zufällig und es kommt einfach eine neue Kombination raus. Ob diese Kombination jetzt gut war entscheidet die Umgebung durch die natürlich Auslese. Ein Gnu das nicht laufen kann wird schnell Opfer eines Löwen -> die Gene dieses Gnu werden sich nicht weiter verbreiten. Wenn es nicht bei der Herde bleibt sondern alleine rumläuft wird es auch schnell gefressen -> Gene verbreiten sich nicht. Kann es gut laufen und bleibt in der Herde überlebt es lange genug seine Gene weiterzugeben. Dadurch kommen viel mehr Gnus mit guten Beinen und Herdenzusammenhalt auf die Welt. Die "Evolution" hat die schlechten Beine und Einzelgängertum aussortiert. Evolution in der Praxis Ein kleines Beispiel weil ich es so toll finde ;) (Keine Ahnung ob es 100% korrekt ist, veranschaulicht das ganze aber gut): Birkenfalter sind Schmetterlinge die bevorzugt auf Birken sitzen. Normalerweise sind sie weiß, weil sie dadurch auf den weißen Birken gut getarnt sind. Jetzt ist es passiert das durch äußere Umwelteinflüsse die Birken sich dunkel gefärbt haben. Innerhalb von 2 Generation waren alle Birkenfalter schwarz. Nicht weil die "Evolution" gesehen hat das schwarze Falter jetzt besser sind. Schwarze Birkenfalter sind zuvor genauso (durch die zufälligen Mutationen) auf die Welt gekommen. Sie wurden nur immer schnell gefressen weil sie keine Tarnung hatten. Mit den dunklen Birken, hat sich das umgedreht und die schwarzen Falter überleben und pflanzen sich fort, während die Weißen gefressen werden. Evolutionsalgorithmen vs. klassische Softwareentwicklung Jetzt muss man das Ganze nur noch auf die Software übertragen. Ein "normales" Programm unterscheidet sich aber doch deutlich von einem lebenden Organismus. Vor allem weil ein Programm für einen konkreten Zweck geschrieben wird. Optimiert für diese Umgebungsbedingungen. Es implementiert normalerweise einen konkreten Lösungsweg, der lt. Entwickler der Beste für dieses Problem ist. Hier gibt es keine Überproduktion und keine Auslese.Es gibt eine konkrete Ausprägung der Spezies und aus. Solange die Umgebung gleich bleibt, und der Entwickler zu Beginn wirklich den besten Lösungsweg kennt ist das Programm auch optimal. Da wäre Evolution fehl am Platz. Wer will schon einen Taschenrechner der immer wieder mal ein anderes Ergebnis liefert und schaut obs jetzt näher an der Lösung ist. Hat man aber ein Problem mit veränderlicher Umgebung, und dessen Lösung nicht so leicht analysierbar ist, dann ist das Prinzip der Evolution sehr hilfreich. Bleibt die Frage wie ein Evolutionsalgorithmus funktioniert. Der generische Evolutionsalgorithmus Wir brauchen als erstes einmal Gene, die man verbessern kann. Also Parameter für unseren Algorithmus. Das müssen aber nicht nur Parameter im Sinn von Zahlen sein. Hier können/sollen auch ganze Teile der Logik als Parameter vorkommen. Es kann also sein das es nicht nur den Parameter "Stärke der Beine" gibt sondern auch einen "Habe ich Beine?". Bzw. Tradingrelevanter: "SL Entfernung" oder "Gibt es überhaupt einen SL?". Oder "Welche Einstiegslogik wird verwendet?". Dann braucht es die natürliche Auslese. Oder technischer ausgedrückt: Wir benötigen eine Bewertungsmöglichkeit der einzelnen Genkombinationen. In der Natur erhält ein Tier eine "hohe Bewertung" wenn es lange überlebt. In der Softwareentwicklung gibt es eben eine hohe Bewertung je besser der resultierende Algorithmus das Problem löst. Kommen wir zur Überproduktion: Jene Genkombinationen, welche die besten Bewertungen haben, werden miteinander "gekreuzt" und teils mutiert. Diese Kreuzung und Mutation muss dermaßen ablaufen das wieder ein lauffähiger Algorithmus entsteht (zumindest meistens, Fehlgeburten gibt es in der Natur auch häufig). Je besser die Bewertung einer Kombination, desto öfter wird sie weitergegeben. Die neue Generation wird nun erneut bewertet und die besten Genkombinationen dürfen sich wieder fortpflanzen, die schlechten werden aussortiert. Und fertig ist der Evolutionsalgorithmus. Sofern alles passt hat man nach ein paar (hundert/tausend/keineAhnung) Generationen einen Satz von Algorithmen, die das Problem gut lösen. Das gute daran: es ist keine Blackbox. Man schaut sich die Genkombination an und weiß was der Algo tut. In der laufenden Praxis kann man damit dann natürlich Algorithmus ständig an geänderte Umgebungsbedingungen anpassen. Es gibt einfach regelmäßig Fortpflanzungen und die Algos werden laufend bewertet. Schlechte Algos sterben aus, gute dürfen sich fortpflanzen... ein ewiger Kreislauf. Im Gegensatz zur klassischen Entwicklung hat man damit zwar immer einen kleinen Teil von Algos die nicht optimal laufen, aber dafür ist man flexibel und das System (Softwaretechnisch) findet selbstständig funktionierende Algos und passt sich somit automatisch an eine veränderte Umgebung an. Soweit die Theorie. Zur Anwendung im konkreten Projekt kommen wir im nächsten Eintrag. thx for reading.

hier die aktuellste Version: eKIvsEvo.mq4 Die NNs können scheinbar aus den reinen Chartdaten noch kein "Muster" lernen. Die KI Variante ist also programmiertechnisch eingebaut, aber tradingtechnisch nicht wirklich zu empfehlen...

kurzes Update: wenn man ihn langsam antrainiert (zuerst mit wenig trainingbars) akzeptiert er auch mit 2 inneren Schichten die Inputs. Aber es bleibt dabei, entweder er lernt die Trainingsmenge auswendig oder er bleibt auf ~60% Fehler. Also Test ist immer ~60% Fehlerquote

also bei mir läuft google auf firefox auch ohne anmeldung einwandfrei. sogar mit scriptblocker... vielleicht hilft der bei dir. Nicht das ein wildgewordenes script schuld is

irgendwelche blocker aktiviert? JavaScript etc...

Wird Zeit für ein neues Update: Auf meinem Rechner läuft jetzt seit ca. 1 Woche ständig irgendein Trainingsdurchlauf. MT nutzt zwar leider nur 1 Kern (ja man könnte es mit mehreren Installationen parallelisieren) aber da ich ja eigentlich selber beim "lernen" bzw. Erfahrung sammeln bin, und unter der Woche nicht gerade viel freie Zeit hab, passt das ganz gut. Wie gehe ich derzeit vor Ich habe einerseits eine mqh, die mir die Vorbereitung der Inputs (Erstellung des Inputvektors inkl. Normierung) und die gewünschten Outputs erzeugt, sowieso ein paar weitere Kapselungen für den Einsatz in einem EA liefert. zB getSignalFromNN() oder updateNN(). Sprich diese mqh enthält die Erweiterung des "allgemeinen NN" auf das "projektspezifische NN". Auch mit einer Funktion trainNN(int offsetBars, int barsInTraining), getCurrentNNError(int offsetBars, int barsInTest) etc. Was es derzeit "lernt" Zuerst habe ich die Outputs so gewählt das ein "positiver Move" vorhanden war wenn der Kurs mindestens x rauf und maximal y runter gegangen ist. Das ganze gleich mal mit einem 5 schichtigen Netz trainiert auf 1000 Bars. Nunja, das Netz/der Backprop ist so "intelligent" das er einfach den Input ignoriert und immer das rät was am häufigsten vorkommt (rauf/runter oder seitwärts). Also nicht wirklich brauchbar. Dann hab ich versucht die Kategorien aufzuweichen und rein auf die Differenz Close-Open des nächsten Bars zu gehen. Also "positiver Move" wenn Close-Open > x. Bei mehrschichtigem Netz der gleiche "Erfolg". Dann hab ich das Netz mal deutlich zurückgefahren und trainiere mal mit nur 1 inneren Schicht. Hier werden die Inputs zumindest nicht mehr ignoriert. Bei 1000 Trainingsbars lernt er jedoch scheinbar recht bald die Trainingsdaten auswendig, denn der Trainingserror geht runter (gestoppt bei 30% Fehler) wobei der Testfehler bei 60% blieb... möglicherweise wird der Testfehler mit der Zeit besser. Derzeit läuft jetzt ein Training auf 5000 Bars, mal sehen ob er da weniger auswendig lernt. Mögliche Gründe Warum er mit mehr als 1 inneren Schicht die Inputs ignoriert ist mir nicht ganz klar. Hier werd ich noch mehrere Test machen müssen. Warum er jedoch nicht so gut lernt bzw. wenn dann auswendig lernt könnte aus meiner Sicht folgenden Grund haben: Ich gebe ihm alle Bars und "hoffe" das er von alleine eine Struktur dahinter erkennt und diese lernt. Das ist natürlich etwas optimistisch. Es gänge vermutlich deutlich besser wenn man das NN zB auf ein konkretes Pattern trainieren lässt und ihm zum lernen eine Reihe klassischer Beispiele dieses Patterns gibt. Hiefür muss man aber zuerst ein Pattern finden das wirklich Aussagekraft hat. Das finden solcher Patterns ist aber bereits Thema des Evolution-Teil dieses Projektes, weswegen ich hier nicht auf diese Taktik wechseln werde, sondern weiter versuche eine Möglichkeit zu finden das NN auf den rohen Daten zu lernen. UPDATE Habe jetzt ein Netz mit 2 inneren Schichten "antrainiert". Mit 30 Bars als Input macht es ein schönes Overfitting: 2% Fehler am Training, 72% am Test. Die 500Bars Back auf 5000 Bars trainiert tümpeln noch immer bei 60% training und test error herum.

Richtige Threadlücke nicht gefunden? SCNR

Ja würd ich gern/hab ich. Der Quote-tag hat scheinbar die Leerzeichen am Zeilenanfang wieder gelöscht. Ich werds mir nochmal anschauen. Beim 2. Versuch scheints geklappt zu haben, hoffe jetzt is es leichter lesbar. Den gesamten Code gibts eh auch im Downloadbereich. Da is es sicher "richtig" eingerückt.

Also gegen 0.6 % is das Angebot von zB der Ing Diba ja nicht schlecht. Nach den 6 Monaten sinds zwar wieder nur 1.5% aber in 6 Monaten kann sich sowieso viel ändern. Ich persönlich würd so Dinge wie CHF kaufen etc. derzeit nicht machen. Es ist einfach immer spekulativ und mMn das Risiko nicht wert. Derzeit wärs vermutlich das Beste möglichst wenig freien Cash zu haben, sprich in Sachwerte investieren. Aber ich bin auch grad in der Situation: "zuwenig um was sinnvolles zu machen, zuviel als das wurscht wär"...