Mythos

respekt ;) selbstverdient, ergaunert oder geerbt?

Respekt. Da ich wie immer neugierig bin: d.h. du hast einen Webserver laufen auf dem der Serverseitige Teil läuft, die App ist eine Webview die sich zum server verbindet. Der Server hat eine aktuelle Kopie der Dropbox (mit Index, so wie es klingt Windowsrechner mit standard windows-index). Die App schickt dann die Anfrage mit dem Suchbegriff, der Server schaut welche files passen und gibt dir die Liste retour? Klingt fancy ;)

So gut gemeint solche Quotenregelungen auch oft sind, so sehr gehen sie teils in der Praxis nach hinten los. Fallbeispiel aus dem universitären Bereich: Bei uns am Institut (also damals als ich auch am Institut war ;) gab es immer schon deutlich weniger Frauen als Männer (warum das im mathematischen Bereich so is sei dahin gestellt, angeblich sogar genetisch argumentierbar), trotzdem muss es in den wichtigen Gremien und bei der Stellenvergabe eine gewisse Frauenquote geben. Gleichberechtigung in der Theorie schön und gut, die Praxis war folgende: Bei der Wahl in die Gremien wurden immer sämtliche zu Verfügung stehenden Frauen genommen (um die Quote hinzukriegen) und bei den Männern wurden die qualifiziertesten gewählt. Dadurch wurden die beteiligten Frauen zu den größten Kritikern der Quote weil es für sie nicht dieselbe Qualifikationsbestätigung war wie für die gewählten Männer. Mir wurde damals von einer persönlich bestätigt das sie lieber keine Quote hätte.

Also selbst wenn alles korrekt ist: erinnert mich ein bissl an "wenn man muster finden will, findet man sie"... Und ganz brutal formuliert: Nehmen wir an das sind alles keine Zufälle... so what? Könnte man dann sagen das 2060 ein Präsident gewählt wird der erschossen wird und Kennicon heißt? Nicht falsch verstehen, ich find synchronizitäten spannend, aber man darf sie nicht falsch/über- bewerten.

Mal ehrlich, wie dumm muss man sein um so eine Aktion zu machen? Keine Frage er hat mehr Glück als Verstand gehabt, aber mit etwas mehr Verstand hätte er das Glück nicht gebraucht...

Sehr schick, ihr beide und das Auto! Typisch cxalgo, wenn schon dann auch richtig http://www.tom-next.de/community//public/style_emoticons/default/loungelizard.gif

Etwas verspätet aber natürlich auch von mir die besten Wünsche!

Ok, die Optimierungen sind durch: Sowohl mit MA-Filter alleine, als auch mit ATR-Filter allein sowie in Kombination lassen sich die Ergebnisse verbessern. Und die Kombination ist auch besser als die einzelnen. Ich werd jetzt mal in einen forwardtest gehen und jeweils einen MA, einen ATR und eine Kombi laufen lassen und schaun was passiert. btw. derweil lass ich alles nur auf EURUSD laufen weil ich sonst keine Daten hab. Weiß wer wo ich halbwegse M1 Daten für andere majors herkrieg?

Nö, das war "as i remember" SQLite ;) hast Recht es is "ON", hab noch gewusst das eines für liste von spalten ist und eines für die Bedingung... Das "==" is halt schon so automatisch bei Vergleichen http://www.tom-next.de/community//public/style_emoticons/default/moveaway.gif bzgl Case: wenn es nur genau eine Abfrage ist, gehts so, aber dann wärs fast besser es als "switch" in den Code zu packen, weil bei 6 Möglichkeiten wird das CASE ein bissl unübersichtlich

Bin ich der einzige der sich fragt was die 8 rechts in der Mitte macht?

Also wenn du in einer tabelle eine int-Spalte TradeTyp hast, wird in der Spalte nie buy oder sell stehen. Du kannst aber beim auslesen der tabelle nicht die tabelle selbst sondern ein JOIN nehmen ala "SELECT * FROM (TM_HistoryOrders JOIN TM_OrderTypes using (TM_HistoryOrders.TradeTyp ==TM_OrderTypes.typeId))" damit kombinierst du die zwei tabellen derart, das zu TM_HistoryOrders Spalten von TM_OrderTypes (für die Ausgabe) hinzugefügt werden. Und zwar genau die Zeile von TM_OrderTypes in der der entsprechende Wert von TM_HistoryOrders.TradeTyp passt. also zB TM_HistoryOrders: id | TradeTyp | .... 1 | 2 | orderinfo1... 2 | 1 | orderinfo2.... TM_OrderTypes: typeid | name 1 | BUY 2 | SELL 3 | BUY_LIMIT .... dann gibt das JOIN folgenden Output (sortierung "zufällig") id | TradeTyp | .... | name 1 | 2 | orderinfo1... | SELL 2 | 1 | orderinfo2.... | BUY damit das ganze auch recht schnell geht, sollte natürlich bei den OrderTypes die typeID der PrimaryKey oder zumindest ein Index sein.

Sollte da eine Grafik sein die verloren ging? (klingt so)

In dem einen Blogbeitrag der hier gepostet wurde stehen einige interessante Punkte. Einerseits natürlich große Resourcen, aber vor allem auch das Anycast und damit die Verteilung auf viele Rechenzentren. Dadurch reduziert sich der Schaden von so verteilten Angriffen natürlich deutlich. Aber so eine Server-Infrastruktur muss man sich halt auch mal leisten können.

back to topic: Ich hab im Moment 3 mögliche Filter eingebaut: - MA Filter: Differenz zwischen schnellem und langsamen MA muss einen Schwellwert überschreiten (also nur in Trendphasen) - ATR absolut: ATR muss größer als Schwellwertsein - ATR relativ: ATR muss größer sein als ein ATR mit langer Periode*Faktor Alle 3 Varianten verbessern 2011 in der optimierten Version das Ergebnis (wenn auch nicht schlimm viel) zB der absolute ATR: statt 6847 macht man mit ATR(13) > 90 Pips 7185 Gewinn Aber im Forwardtest 2012 sind die Resultate immer schlechter als 2012 ohne Filter. Am besten ist noch der MA-Filter mit ABS(MA(3) - MA(90)) > 60 wo zumindest der PF raufging in 2012. Ich mach jetzt mal eine Optimierung auf 2012 um zu sehen ob es überhaupt Varianten gibt wo der Filter 2012 das Ergebnis verbessert. Aber es scheint das man für dieses System wirklich alles vor 2012 vergessen kann...

Hab ein bissl weiter getestet und ein paar "spannende" Erkenntnisse: Also der ATR Filter (und auch andere Filter in diese Richtung) helfen vor 1.1.2012 wunderbar. Da geht der PF von 1.98 auf bis zu 4 rauf. Im Jahr 2012 hilft es leider nicht mehr viel bzw. verschlechtert das Ergebnis eher. Sehr interessant ist auch die Erweiterung auf mehrere Tage: Im Jahr 2011 ist der Gewinn beim Schließen der Position am Abend auf ca 6000 bei 1000 Risiko pro Trade. Erweitert man die Haltedauer auf bis zu 2 Tage geht der Gewinn auf 20000. Im Jahr 2012 ist es dann umgekehrt: Mit Schließen am Abend: ca 6000 Gewinn (PF 1.46) bisher Haltedauer 2 Tage: 4500 Gewinn (PF 1.18) 2010 is sehr ähnlich wie 2011. Es scheint, als wären vor 2012 mehr Trends die mehrere Tage halten und inzwischen die Bewegungen stärker schwanken und es stärker rauf und runter geht. Aus dem Grund hab ich jetzt noch einen "EveningStop" eingebaut, sprich wenn es über mehrere Tage geht, wird jeweils am Abend der Stop stärker als üblich nachgezogen, damit nicht zuviele Gewinne abgegeben werden. Das sorgt vor 2012 natürlich dafür das man deutlich unter den 20000 zurückbleibt. Aber mit ca 7700 ist es zumindest besser als mit schließen der Position am selben Tag. Und das schöne: diese Performance geht konstant weiter ins Jahr 2012, auch hier liegt der Gewinn im Moment bei ca. 8000. Hier sind aber noch keine ATR-Filter drauf, die kommen jetzt als nächstes.

Naja so kompliziert ist das nicht. Ein EA muss sowieso grundsätzlich schaun welche aktuell offenen Orders von ihm sind um nicht mit anderen EAs zu konkurieren. Im Gegensatz zu mt5 kann man im mt4 dafür mehrere EAs unkompliziert am gleichen Symbol laufen lassen. Hat alles seine Vor- und Nachteile.

Ja sowas kann einem ganz schön den Tag vermiesen. btw.: nicht falsch verstehen, aber wenn der erste Post im Forum in diesem Thread ist, einen Link auf "ähnliches , eigenes System" bei myfxbook beinhaltet und dieses myfxbook-system auch noch innerhalb von 1 tag 6% rauf geht, aber -12% openProfit hat, dann werden wir ein bisschen misstrauisch. Vielleicht wars ja auch nur ein schlechter Start, auf jeden Fall herzlich willkommen bei uns.

Das stimmt, aber wenns darum geht eine Reihe von Regeln auf ein Pattern zu matchen ist die pessimistische View glaub ich die bessere. Weil wenn ich sage "High gestern Low gestern ...." macht es wenig Sinn wenn die Regeln im Median gut matchen. Also zB 2 gar nicht 3 perfekt, da is der Median dann 100%....

Also wenn ATR

Ich schau mir grad das System nochmal genauer an und wollte mal fragen ob das "Morgen" schon war ;) An sich sieht es ja recht gut aus.

Und wieder hat es eine halbe Ewigkeit gedauert seit dem letzten Eintrag. Der Grund ist neben den technischen Problemen hier leider wieder in anderen Verpflichtungen und einer fiesen Erkältung zu suchen. Aber jetzt gibt es endlich wieder was erwähnenswertes also los gehts: was bisher geschah Nachdem die erste Version der CDL fertig war, entstanden sofort Generationen von Pattern mit über 90% Trefferquote. Wie zu erwarten war beruhte diese Trefferquote rein auf Denk- und Programmierfehlern. Also mussten zusätzliche Filter und Korrekturen rein. Danach waren die Generationen nicht mehr so schnell erfolgreich (die Trefferquote blieb meist knapp unter 50%) aber gelegentlich fand sich doch ein glücklicher Ausreißer. Bei genauer Analyse ergab sich, das auch diese Erfolge in der Praxis schwer umsetzbar sein würden da die Mindestbewegungen in den Targets zu klein waren. Um dem Abhilfe zu verschaffen hab ich bei der Überprüfung der Bewegung den Spread miteinbezogen und eine Untergrenze für die minimale Bewegung eingeführt. Und siehe da, die Trefferquoten waren verheerend. In der Hoffnung auf Besserung hab ich mehr Möglichkeiten für die Evolution eingebaut (SMA für die Preisrelation..) und versucht die Filterung und Mutation zu "verbessern" ... Mit dem Erfolg das die Trefferquoten von "schlecht" auf 0% fielen. Wie sich das auf meine Motivationskurve ausgewirkt hat kann sich vermutlich jeder denken :( Eine Problemanalyse Nachdem mehrere 10000 Generationen auf 0% blieben hab ich mir gedacht "Das kanns doch nicht sein". Selbst das "dümmste" Pattern sollte doch zumindest gelegentlich treffen. Nach langer Analyse blieb nur eine logische Erklärung: Die erzeugten Patterns matchen zu selten, weil sich die zufälligen Regeln gegenseitig blockieren. Zugegeben in dem Moment hatte ich schon soviel probiert das "logische Erklärung" falsch ausgedrückt ist und nur durch den nachträglichen Erfolg begründet ist. Am Anfang der Evolution bzw. wenn die Generation komplett erfolglos blieb, hab ich zufällige Patterns erzeugt. In Vertrauen auf den Zufall hatten diese zufälligen Patterns eine zufällige Anzahl von zufälligen Regeln. Die Regeln wurden zwar halbwegs "sinnvoll" erzeugt aber das Verhindern von Widersprüchen hab ich der Evolution (und dem Zufall) überlassen. Nach dem Prinzip "Lass Affen lang genug auf eine Schreibmaschine einhauen und du erhältst irgendwann einen literarischen Klassiker". Aber auf den Zufall ist leider nicht genug Verlass, es bedarf doch einer gewissen Steuerung von außen. Gesagt getan: Nun gibt es bei neuen zufälligen Patterns immer nur 1 zufällige Regel (und natürlich das Target). Dafür hab ich die Wahrscheinlichkeit für neue Regeln im Zuge der Evolution erhöht. Sprich ich bin von "Das perfekte Pattern als ganzes erraten" auf "Einen akzeptablen Start raten und dann sukzessive verbessern" gewechselt. Und es funktioniert zumindest mal besser als vorher. Von 0% ist die Trefferquote zumindest mal wieder auf meist knapp unter 50% gestiegen. Im H4 hat sich bisher sogar ein Pattern mit 77% gefunden. Zugegeben ich hab mir noch nicht angeschaut ob das wieder irgendein blöder Fehler ist, aber zumindest "funktioniert" die Evolution wieder etwas besser. Es sind sicher noch einige Verbesserungen nötig, aber ich hab zumindest wieder das Gefühl in der richtigen Richtung unterwegs zu sein ;)

Wenn das funktioniert is es natürlich die bessere Möglichkeit.

ja die neuen Inhalte verwende ich auch am meisten...

Hab mal nachgeschaut was die ganzen User machen. 90% der Gäste "sucht...". Ich weiß jetzt nicht wie effizient der Suchalgo hier ist, aber ich tippe mal das er das performanceintensivste ist, das die Page zu bieten hat. Würde es helfen die suche temporär "abzudrehen"? natürlich nur vorübergehend, vielleicht kann man damit den Server entlasten. Frage in die Runde: wen würde es stören wenn die Boardinterne Suche mal 1 Woche nicht läuft? Weil es is schon etwas ungewöhnlich wieviele Gäste gleichzeitig suchen. Ich tippe mal die Suchbegriffe sind auch nicht von der einfachsten Sorte....