Liebe Community-Mitglieder,

 

ich brauche mal ein wenig Hilfe bei der Programmierung. Und zwar geht es darum, dass ich drei verschiedene Handelssysteme auf den FDAX (Sub1 bis 3) am laufen habe, aber eigentlich nur eine Position handeln möchte.

 

Um den nächsten Schritt des Systemhandels zu gehen, steht folgende Idee im Raum: es soll nur (mittels eines Mastersystems) in die aktuelle Richtung des Systems gehandelt werden, welches bspw. in den letzten 4h am profitabelsten war. Die Idee kam dabei von jemanden, der diesen Ansatz mal testweise in Investox umgesetzt hat. Dort sah es sehr profitabel aus, nur leider war die Datenbasis zu gering, so dass ich mich nun frage, ob das mit dem Metatrader auch geht.

 

Ich denke dabei daran, dies über einen kleinen Umweg zu machen. Dieser könnte wie folgt aussehen: die einzelnen Subsysteme handeln nicht, sondern dienen Indikator bzw. werden dazu umgebaut. Ich benötige dabei zum einen den Status der Subsysteme (long, short, flat) als auch den jeweiligen "Profit" bspw. der letzten 4h (dies wäre per Backtest zu optimieren). Dabei ist zu beachten, dass die Subsysteme in der Zwischenzeit ja auch ihre Position verändert haben könnten - nur den aktuellen Status mit der Kursdifferenz im Underlying zwischen jetzt und vor 4h zu multiplizieren reicht also leider nicht.

 

Das Mastersystem bräuchte dann "nur" die Indikatoren abgleichen und nach dem "besten" long oder short gehen bzw. dann später die Position drehen (Details wann wo wie folgen).

 

Nun die Fragen:

- kann ich ein System (inkl. Profitkurve) zu einem Indikator "umbauen"?

- wenn ja: wie kann ich diese Daten (Status und Profit der Subsysteme) dann in das Mastersystem übergeben?

- ist überhaupt verständlich, was ich bezwecke ;)?

 

So viel sei gesagt: ich habe keine Angst vor Programmcodes, nur überwiegen bei mir eher die Ideen und das basteln als dass ich etwas "aus dem Nichts" programmieren könnte. Leider sind meine MQL Kenntnisse nicht so weitreichend, als das ich das hinbekommen würde. Falls also jemand Lust und Zeit hat, mir dabei zu helfen, ist das super.

 

Falls es "zu viel" Aufwand ist, kann man sich auch gerne per Boardmail über Details einer möglichen "Bezahlung" austauschen.

 

Vielen Dank vorab schon mal an alle, die aufgrund meines Textes hier ihren Kopf rauchen lassen .

 

P.S.: ich hoffe, ich habe die richtige Kategorie für mein Topic ausgewählt. Sonst bitte in Handelsansätze / Strategien o.ä. verschieben.

Bearbeitet 13. April 200917 Jr. von conglom-o

Meinem Verständniss nach hat die Version MIT der Möglichkeit, mehrere (egal, wie viele) Systeme miteinander zu verknüpfen den Fehler, daß nachdem ein System mit Gewinn gefunden ist, die restlichen Systeme nicht mehr überprüft werden.

Wie kommst du zu der Vermutung? aufgrund von Tests oder Analyse des Source Codes?

 

Da es sicher viele Mitleser freuen wird, gehen wir einfach mal Schritt für Schritt die entsprechende Funktion durch, vielleicht finden wir ja den Fehler.

 

[ 1]int getDirection()
[ 2]{
[ 3]  int index=0,direction=0;
[ 4]  double current_best=0,slope=0,last_slope=0,roc=0,comp=0;
[ 5]  bool got_one= false;
[ 6]  
[ 7]  for(index= 0;index < ArraySize(systems_);index++)
[ 8]  {
[ 9]    slope= iCustom(Symbol(),Period(),systems_[index],RegressionPeriod,AveragePeriod,0,0);
[10]    if(ROC_Period == 0)
[11]      roc= slope;
[12]    else
[13]    {
[14]      last_slope=iCustom(Symbol(),Period(),systems_[index],RegressionPeriod,
                            AveragePeriod,0,ROC_Period); 
[15]      if(last_slope != 0)
[16]        roc= slope/last_slope-1; 
[17]      else
[18]        roc= 0;
[19]    }
[20]      
[21]    if(CompareSlope)
[22]      comp= slope;
[23]    else
[24]      comp= roc;
[25]      
[26]    if(roc > 0 && comp > 0 && got_one && Unique)
[27]        return(0);
[28]      
[29]    if(roc > 0 && comp > current_best)
[30]    {
[31]      got_one= true;
[32]      current_best= comp;
[33]      if(iCustom(Symbol(),Period(),systems_[index],RegressionPeriod,AveragePeriod,1,0) > 0)
[34]        direction= 1;
[35]      else if(iCustom(Symbol(),Period(),systems_[index],RegressionPeriod,AveragePeriod,1,0) < 0)
[36]        direction= -1;
[37]      else
[38]        direction= 0;
[39]    }
[30]  }
[41]  return(direction);
[42]}

got_one hat die Aufgabe, sich zu merken ob bereits ein System mit Gewinn (im Sinne wie wir es definieren) gefunden wurde oder nicht.

Da man wählen kann ob man die Steigung der RegLine vergleicht, oder die ROC der STeigung der RegLine, übernimmt die temporäre Variable "comp" die Aufgabe des zwischenspeicherns.

roc= ROC der RegSlope sofern diese sinnvoll definiert ist (slope von vor ROC_Period bars > 0)

current_best ist unsere erinnerung, was der bisher beste Wert von comp war, da wir für Gewinn "comp > 0" vorraussetzen, merken wir uns nur dinge die größer als 0 sind, also beginnt current_best bei 0.

 

die for-schleife die in [7] beginnt läuft über den gesamten Rest der Funktion, alles danach passiert also für jedes subsystem, außer wir brechen vorher ab.

[9]... wir holen uns den RegSlope aus dem System

[10]-[19] wir berechnen die roc des RegSlope.

[21]-[24] wie oben erwähnt: comp wird entsprechend gesetzt,

d.h. ab jetzt hat slope, roc und comp die Werte für das aktuelle system.

[26]-[27] hier kommt die frage nach dem Unique:

Unique bedeutet: "Es herrscht ein Signal für den Master, wenn genau 1 System gewinn macht"

"Gewinn machen" ist definiert als: positive ROC (also die performancekurve steigt) und positive (slope oder roc, je nach parameter)

Wenn jetzt "got_one" true ist, es also bereits ein system mit gewinn gibt, und Unique aktiv ist und das aktuelle system gewinn macht, dann bricht die Funktion ab und gibt 0 retour, was für den Master bedeutet "tu nix" bzw. flat.

[29]: current_best speichert den bisher besten Wert von comp der gefunden wurde. (bzw. bleibt 0 wenn es keine werte > 0 gibt) hier wird also abgefragt "Gewinn und besser als alles was bisher betrachtet wurde".

Ist die Antwort "ja" so speichern wir uns in [33] - [39] die aktuelle Richtung des Systems in die Variable direction und merken uns mit [31] das wir ein System mit Gewinn haben, und mit [32] den comp-Wert von diesem System

Danach beginnt der nächste Schleifendurchlauf und wir machen alles fürs nächste System.

In [41] wird nun die gespeicherte Richtung retouniert, sofern nicht vorher irgendwann in [27] abgebrochen wurde.

 

Nach meinem Verständniss, wird also jedes System betrachtet und die Richtung des besten gewinnt. Wo die Reihenfolge eine Rolle spielt, ist wenn 2 Systeme die gleichen Werte für comp aufweisen aber unterschiedliche Marketpositionen haben, dann gewinnt das erste System. Aber diese Sensitivität gegenüber der Reihenfolge kriegt man nicht weg.

 

Wenn man Unique= false setzt, seh ich bei gleichen Subsystemen, nicht wie es zu unterschiedlichen Ergebnissen bei unterschiedlicher Reihenfolge kommt.

Sicher das alle restlichen "Umgebungsvariablen" gleich sind?

@Mythos

Vielen Dank für die Ausführungen. So etwas ähnliches hatte ich mir schon gedacht, nur wird es so natürlich klarer .

 

Folgende Fragen werfen sich ja derzeit auf:

- warum unterscheiden sich die Ergebnisse (u.U. gravierend) des Backtest wenn man...

a) nur die Reihenfolge der Indikatoren wechselt (Details unten)?

b) das Startdatum des Backtests ändert (hier rede ich davon, dass selbst nach einer großzügigen "Einschwingphase" die Trades nicht gleich sind)?

- warum ist man mittlerweile gewillt, ohne großes Nachdenken einfach das "falsche" System zu nehmen, welches ja Plus macht ?

 

Backtestergebnisse (Reihenfolge - Profit - DrawDown):

1.2.3: +4718 - 1485

1.3.2: -269 - 1807

2.3.1: +88 - 2362

2.1.3: +4718 - 1485 (siehe 1.2.3)

3.2.1: siehe 2.3.1

3.1.2: siehe 1.3.2

 

Es zeigt sich, dass anscheinend nur die ersten zwei Systeme in der Liste den Ausschlag geben. Dies wird durch eine testweise Erweiterung auf vier Subsysteme bestätigt. Eine Systematik was die unterschiedlichen Ergebnisse bei verschiedenen Startzeitpunkten angeht, habe ich leider noch nicht gefunden .

Die erste Frage die sich aufdrängt:

mit welchem Master wurde gestestet? ich hab die aktuellste Version "analysiert", die alte Version hat noch einen Bug.

 

Und dann kommt der Debugoutput an die Tagesordnung.

Print-Statements in die Vergleichsschleife, die alle nötigen Infos ausgibt, und das ganze im visuellen Modus testen.

bzw. liefert eine visuelle überprüfung welche trades unterschiedlich sind vielleicht schon erkenntnisse.

 

Wurde mit Unique= true getestet? Wenn ja: wie sieht es bei false aus.

 

Oder hängt es möglicherweise an der einlesfunktion und er liest nur die ersten 2 subsysteme ein?

 

Also die Analysemöglichkeiten sind noch lang nicht erschöpft, jetzt fangt es erst an spannend werden ;)

 

Jetzt kommen die 80% der Arbeitszeit, die beim Systementwickeln immer so lästig sind *ggg*

Die erste Frage die sich aufdrängt:

mit welchem Master wurde gestestet? ich hab die aktuellste Version "analysiert", die alte Version hat noch einen Bug.

Habe mit dem aktuellen getestet, 6 Monate Backtest.

 

Wurde mit Unique= true getestet? Wenn ja: wie sieht es bei false aus.

Oder hängt es möglicherweise an der einlesfunktion und er liest nur die ersten 2 subsysteme ein?

 

Test war bei Unique= True. Beim Test von false ergab sich folgendes Bild:

1.3.2 = 3.1.2 (wie gehabt)

2.1.3 = 2.3.1 (anders als vorher)

1.2.3 und 3.2.1 haben nun keine Partner.

 

Es lag zunächst der Verdacht nahe, dass (bei Unique true) evtl. immer das letzte System in der Reihe vergessen wird. Deswegen haben wir es mal mit vier Systemen getestet. Ergebnis war, dass 1.2.3.4 = 2.1.3.4 (erstes und zweites vertauscht, passt), aber ungleich 1.3.2.4 (zweites und drittes vertauscht, passt nicht) ist (Angaben beruhen auf den Tests von GoSPvC). Diese Logik kommt also auch nicht hin. Er liest also mehr als zwei (bzw. n-1) Systeme ein. Der nächste Schritt wird das einpflegen von ein paar Print-Befehlen sein, damit ich weiß, aufgrund welches Subsystems er welchen Trade macht.

Wie kommst du zu der Vermutung? aufgrund von Tests oder Analyse des Source Codes?

 

 

got_one hat die Aufgabe, sich zu merken ob bereits ein System mit Gewinn (im Sinne wie wir es definieren) gefunden wurde oder nicht.

...

current_best ist unsere erinnerung, was der bisher beste Wert von comp war, da wir für Gewinn "comp > 0" vorraussetzen, merken wir uns nur dinge die größer als 0 sind, also beginnt current_best bei 0.

...

[26]-[27] hier kommt die frage nach dem Unique:

Unique bedeutet: "Es herrscht ein Signal für den Master, wenn genau 1 System gewinn macht"

...

Wenn jetzt "got_one" true ist, es also bereits ein system mit gewinn gibt, und Unique aktiv ist und das aktuelle system gewinn macht, dann bricht die Funktion ab und gibt 0 retour, was für den Master bedeutet "tu nix" bzw. flat.

[29]: current_best speichert den bisher besten Wert von comp der gefunden wurde. (bzw. bleibt 0 wenn es keine werte > 0 gibt) hier wird also abgefragt "Gewinn und besser als alles was bisher betrachtet wurde".

Ist die Antwort "ja" so speichern wir uns in [33] - [39] die aktuelle Richtung des Systems in die Variable direction und merken uns mit [31] das wir ein System mit Gewinn haben, und mit [32] den comp-Wert von diesem System

Danach beginnt der nächste Schleifendurchlauf und wir machen alles fürs nächste System.

In [41] wird nun die gespeicherte Richtung retouniert, sofern nicht vorher irgendwann in [27] abgebrochen wurde.

 

Hi Mythos,

 

Soweit ich conglom-o verstanden habe, soll der Master nicht eingreifen, solange nicht die Situation auftritt, daß alle drei SubSysteme gleichzeitig Verlust produzieren. Nur, wenn diese Situation auftritt, dann soll der Master Checken, wann EINES der Systeme wieder anfängt, Gewinn zu machen und nur in diesem Fall soll der Master die weiteren SubSysteme in die Richtung drehen, in die das eine System mit dem Gewinn handelt.

 

Den Code verstehe ich jetzt so, daß (natürlich der Reihe nach) gecheckt wird, was die Subs abliefern (Gewinn oder Verlust). Wird jetzt (im Unique-Mode) eines gefunden, das Gewinn macht, dann wird got_one true und zusammen mit Unique = true abgebrochen.

 

... Stimmt, eigentlich ist die Logik in Ordnung.

Hab bis jetzt irgendwie immer die Situation: "Alle machen Minus -> EINES fängt an Plus zu machen" vermisst...

 

Hmmm...

Aus congloms Wunsch von hier:

Um den nächsten Schritt des Systemhandels zu gehen, steht folgende Idee im Raum: es soll nur (mittels eines Mastersystems) in die aktuelle Richtung des Systems gehandelt werden, welches bspw. in den letzten 4h am profitabelsten war.

[...]

Das Mastersystem bräuchte dann "nur" die Indikatoren abgleichen und nach dem "besten" long oder short gehen bzw. dann später die Position drehen.

 

Die GRundidee vom MAster (so wie ich ihn implementiert habe):

Alle Subsysteme laufen simuliert, der Master greift bei keinem Subsystem ein sondern beobachtet diese nur.

Die Subsysteme sagen dem Master in welche Richtung sie gerade Positioniert sind und welche Steigung die Regression der Equity hat.

Der Master entscheided dann je nach eingestellter Logik anhand dieser Werte was er tut.

Derzeit ist die Logik so:

Wenn das System, welches die Beste "Steigung" (also höchste comp-Wert) hat im Markt ist, positionier dich so wie dieses System positioniert ist, sonst tu nix (also bleib positioniert wie du warst).

Per Parameter kann man noch sagen ob das Mastersystem auch flat gehen "darf" wenn der beste gerade flat ist, oder es keinen positiven gibt.

 

also wenn alle negativ sind, und einer plötzlich positiv wird, ergibt sich aus dieser Logik, dass sich das System dann gleich positioniert wie dieser einzelne Gewinner. Die Logik ist nur allgemeiner als dieser Spezialfall.

(bzw. wenn Unique= true ist sie fast gleich)

Gedacht war es eigentlich eher so, wie Mythos es geschrieben hat. Der Master soll dann was tun, sobald ein System Gewinn macht. Wenn bspw. alle drei Systeme short drehen, der Markt steigt aber weiter, dann soll er long bleiben und erst drehen, wenn der Markt fällt, spricht die Equity mindestens einer der Subsysteme steigt. Es ist aber für ein Handeln des Masters nicht zwingend erforderlich, dass alle Systeme vorher Verluste machen - das wäre ja irgendwie auch nicht schön so im Alltag. Genauso wenig ist es (bei Unique) erforderlich, dass das System mit der "besten Steigung" maßgebend ist - eine positive Steigung eines der Systeme soll(te) vollkommen ausreichen.

 

Eventuell liegt es ja dran, dass derzeit die Reihenfolge maßgebend ist...

zur Reihenfolge:

Die Reihenfolge spielt (aus sicht des Source codes) nur eine Rolle, wenn 2 System genau die gleiche Performanceentwicklung haben (also momentan gleichen wert von comp), aber unterschiedliche Positionen. das dürfte aber hier selten der fall sein.

Habe nun mal etwas weiter gebastelt und mir eine kleine Abfrage eingebaut, dass das System nicht am Donnerstag und Freitag vor den großen Verfallstagen handeln darf bzw. bestehende Trades schließt. Das sieht (teilweise) so aus:

// Block Trades
bool TradeBlocker = False;
if ((DayOfWeek()==4 || DayOfWeek()==5) && (Month()==3 || Month()==6 || Month()==9 || Month()==12) && Day()>=15 && Day()<= 21) {
  TradeBlocker = True;
  }

[...]

// Orders schliessen
if (TradeBlocker || ((ExitBuy1_1 < ExitBuy1_2) && (Buy1_1 <= Buy1_2))) Order = SIGNAL_CLOSEBUY;

[...]

// Orders öffnen
if ((Buy1_1 > Buy1_2) && !TradeBlocker) Order = SIGNAL_BUY;

 

Nun kommt die große Preisfrage: warum funktioniert das im Handelssystem, nicht jedoch im systembasierenden Indikator? Jemand eine Idee?

Nun kommt die große Preisfrage: warum funktioniert das im Handelssystem, nicht jedoch im systembasierenden Indikator? Jemand eine Idee?

 

Nur aus dem Stück Code könnt ich jetzt nur Mutmaßungen anstellen. Schon mal probiert im Indikator ein "Print(TradeBlocker)" dazuzupacken und schaun welche Werte das Ding hat? Hilft meist einiges.

Problem (teilweise) gelöst . Es lag daran, dass ein EA anscheinend automatisch bei der Wahl von DayOfWeek u.ä. den Tag der Kerze nimmt. Der Indikator nimmt da (korrekterweise) den Tag des aktuellen Serverdatums. Wenn man jedoch die Kerze überprüfen möchte, kann man es bspw. so bauen:

bool TradeBlocker = false;
datetime thisday = iTime(Symbol(),0,0);
if ((TimeDayOfWeek(thisday)==4 || TimeDayOfWeek(thisday)==5) && (TimeMonth(thisday) == 3 || TimeMonth(thisday)==6 || TimeMonth(thisday)==9 || TimeMonth(thisday)==12) && TimeDay(thisday)>=15 && TimeDay(thisday)<= 21) {
  TradeBlocker = True;
}

 

Der nun noch bestehende Fehler ist, dass der Indikator zwar im visuellen Modus nicht jedoch für die von ihm gefüllte Historie richtig macht. Dazu kommt die im Indikator für mich noch nicht nachvollziehbare Berechnung der Equity. Diese scheint mehr oder weniger einem Zufallsprinzip zu unterliegen. Deswegen würde ich sie dann (auch rückwirkend) einfach zu jedem Quartalsende auf 0 setzen wollen. Ich vermute mal, dass dies zusammen erschlagen werden kann. Dies scheint aber wieder eher was für die Freaks unter uns zu sein....

Der nun noch bestehende Fehler ist, dass der Indikator zwar im visuellen Modus nicht jedoch für die von ihm gefüllte Historie richtig macht. [...] Diese scheint mehr oder weniger einem Zufallsprinzip zu unterliegen.

Also die Berechnung der Equity unterliegt definitiv nicht dem Zufallsprinzip. (außer du hast sie geändert)

Beim Füllen der History wird dem Algorithmus von hinten nach vorne jeder Bar einzeln gegeben und die Werte aktualisiert. Ich gehe jetzt mal davon aus, das du beim TradeBlocker aber nicht die Zeit des übergebenen Bars verwendest sondern immer die aktuelle Zeit (btw: iTime tut das gleiche wie Time[0]), hier würde Time (also i der aktuelle Bar) wesentlich mehr Erfolg bringen.

Wie üblich kommen mir die besten Ideen im Schlaf oder unter der Dusche. In diesem Fall war es letzteres. Ich Töffel habe natürlich vergessen, die Verschiebung der Kerzen mit zu berücksichtigen. Das kenne ich ja schon (Mythos weiß, wovon ich spreche ).

 

Korrekterweise muss es also so aussehen (als Basis immer der Beispielindikator aus diesem Thread):

// Trades blocken und Konto auf 0 setzen
bool TradeBlocker = False;
datetime thisday = iTime(Symbol(),0, bar_index + 0);
if (TimeDayOfWeek(thisday) >=4 && (TimeMonth(thisday) == 3 || TimeMonth(thisday)==6 || TimeMonth(thisday)==9 || TimeMonth(thisday)==12) && TimeDay(thisday)>=15 && TimeDay(thisday)<= 21) {
  TradeBlocker = True;
  balance_ = 0;
  position_ = 0;
}

Ich habe hier einfach mal die balance_ auf 0 gesetzt. Ob man es auch alternativ mit der Equity machen kann bzw. sogar muss kann wohl nur Mythos sagen .

Ich habe hier einfach mal die balance_ auf 0 gesetzt. Ob man es auch alternativ mit der Equity machen kann bzw. sogar muss kann wohl nur Mythos sagen .

Umgekehrt: du darfst weder die Equity noch die Balance auf 0 setzen. Bzw. du darfst schon, aber wunder dich dann nicht wenn die Regression plötzlich so tut als würd der Indi grad massig verlieren.

Wenn du eine Position "schließt" und du dich selber um die Positions-(und damit um Gewinn- und Equity-) Verwaltung kümmerst, musst du die geschlossene Position auch dementsprechend in "einbuchen".

Kannst ja in real auch nicht sagen "da is eine Position offen mit 1000 Euro Verlust, aber morgen is der Kontrakt zu Ende, also schmeiß ma die Position weg und tun so als wär sie nie da gewesen."

Umgekehrt: du darfst weder die Equity noch die Balance auf 0 setzen. Bzw. du darfst schon, aber wunder dich dann nicht wenn die Regression plötzlich so tut als würd der Indi grad massig verlieren.

Wenn du eine Position "schließt" und du dich selber um die Positions-(und damit um Gewinn- und Equity-) Verwaltung kümmerst, musst du die geschlossene Position auch dementsprechend in "einbuchen".

Kannst ja in real auch nicht sagen "da is eine Position offen mit 1000 Euro Verlust, aber morgen is der Kontrakt zu Ende, also schmeiß ma die Position weg und tun so als wär sie nie da gewesen."

Danke für den Hinweis. Ich werde es mal live beobachten (nächste Woche ist ja mal wieder Verfall). Ich bin davon ausgegangen, dass der Master ja die Trades macht, die er auch zum Quartalsende (ggf. auch im Verlust) schließt. Somit wollte ich zu jedem Quartalsbeginn in den Indikatoren alles auf 0 setzen. Eventuelle Verlustpositionen sind sowohl im Master und auch in den für die Parameterentwicklung zu Grunde liegenden Subsystemen natürlich berücksichtigt.

 

Das Problem an der Sache liegt nämlich darin, dass die Equity im Indikator nicht gleich mit der des zugehörigen Subsystems ist. Ich betrachte da bspw. nur den laufenden Kontrakt. Insofern war meine Idee, diesen Fehler durch Rücksetzung zu beheben (Datenbasis der laufenden Kontrakte geht meist noch ein paar Wochen zurück). Die Trades sind auf den ersten Blick gleich. Doch leider stimmen die Equitys immer noch nicht überein....

 

Update

Das mit der unterschiedlichen Equity scheint nur einen meiner zwei Anbieter zu betreffen. Woran das liegt, muss man mal im Detail ergründen.

Wenn du ein Rücksetzen des Kontos auf 0 simuilieren willst, musst du die Equity der Vergangenheit auch auf 0 setzen, sonst spielt die Regression verrückt.

 

Update

Das mit der unterschiedlichen Equity scheint nur einen meiner zwei Anbieter zu betreffen. Woran das liegt, muss man mal im Detail ergründen.

Kommission und Swap wird vom Indi nicht berücksichtigt. Und beim eröffnen und schließen der Position kann er auch nur schätzen wo du ausgeführt worden wärst...

Wenn du ein Rücksetzen des Kontos auf 0 simuilieren willst, musst du die Equity der Vergangenheit auch auf 0 setzen, sonst spielt die Regression verrückt.

 

Kommission und Swap wird vom Indi nicht berücksichtigt. Und beim eröffnen und schließen der Position kann er auch nur schätzen wo du ausgeführt worden wärst...

 

Okay, ich probiers mal. Da aber ja so oder so 2 Tage handelsfrei gestellt wird und somit sich die Equity innerhalb dieser Tage eh gleich bleiben würde, dürfte es keine Auswirkungen auf die Regressionen haben. Ich arbeite hier mit 5-Minutenchart und Regressionen / MAs / ROCs im Bereich um 12. Kommissionen und Swap werden bei beiden Anbietern nicht gezahlt - daran liegt es also nicht.

 

Hier mal ein paar Zahlenbeispiele (gleicher Zeitraum, gleiche Tradegröße):

 

Anbieter A

Indikator1: -160

Subsystem1: -145

Indikator2: -407

Subsystem2: -411

Master: -427

 

Anbieter B

Indikator1: -1263

Subsystem1: -871

Indikator2: -2992

Subsystem2: -823

Master: -356

 

Das ist für mich schon so gravierend, dass ich gar nicht weiß, woran das liegen könnte. Bei Anbieter A stimmen wenigstens noch Indikator und Subsystem nahezu überein, bei Anbieter B ist es Kraut und Rüben. Den Unterschied im Master zwischen A und B schiebe ich mal auf die unterschiedliche Datenbasis. Da werde ich aber nochmal die Trades im Einzelnen durchgehen.

 

Update

Habe den Fehler gefunden. Er lag ganz einfach darin, dass ich den Backtest an einem Sonntag gestartet hatte. Da Sonntag aber als Wert den Tag 0 hat, konnte er die Parameter zum Start nicht zurück setzen. Lasse ich den Backtest ab Freitag laufen, stimmen die Werte vom Indikator und Subsystem nun überein. Das erfreuliche daran ist, dass der Master es schafft, aus einem Indikator mit -1263 und einem mit -2925 einen relativ kleinen Verlust von -420 zu produzieren. Und dies in einem Out-Of-Sample Bereich! Nun muss sich nächste Woche zeigen, dass auch im live-Modus Backtest und Trades nahezu übereinstimmen...

So, nachdem ich den Master nun auf zwei Subsysteme reduziert habe, läuft seit Montag ein Test. Bisheriges Fazit nach 3 Tagen: im Vergleich mit dem Backtest stimmt da nicht ein Trade überein. Also so langsam verzweifel ich wirklich an dem Ding....

So, nachdem ich den Master nun auf zwei Subsysteme reduziert habe, läuft seit Montag ein Test. Bisheriges Fazit nach 3 Tagen: im Vergleich mit dem Backtest stimmt da nicht ein Trade überein. Also so langsam verzweifel ich wirklich an dem Ding....

 

Hmm, das klingt ja nicht so doll. Ich hab jetzt den Thread nicht weiter verfolgt, daher kenn ich Dein System auch nicht so gut, aber: sieht es denn im Backtest plausibel aus und funktioniert nur im Livetest aus irgendnem Grund nicht bzw. ist Anbieter-abhängig?

 

Im Moment sieht es für mich so aus, als hättest Du zuviele offene Baustellen. Das verspricht aber außer grauen Haaren meist nichts... ach ja doch.... JEDE MENGE ÄRGER .

 

Theoretisch sollte es doch auch auf 1 Subsystem runterzubrechen sein. Vielleicht ist es auch sinnvoll, das erstmal zu testen, ob es für 1 Subsystem funktioniert, dass der Code generell funktioniert. Eventuell schreib Dir die Trades/Signale/Orders separat in ne Datei mit zusätzlichen Infos wie Zeit/Daten/Bars/wie war die Vola zu der Zeit oder was auch immer für den Unterschied verantwortlich sein KÖNNTE. Ob es auch verantwortlich ist, schaut man dann im nächsten Schritt, wenn man die Orders extern auswertet (R, Excel, OO,...).

 

So kann man bspw. besser und effizienter rausfinden, wo die Unterschiede zwischen den Datenanbietern liegen, OB es überhaupt an denen liegt u.v.a.

@Krümel

Also am Datenanbieter liegt es nicht - es sind ja die gleichen Daten und sogar nur 3 Tage. Heute passen aber bspw. die ersten 2 Trades auf den Punkt und der dritte weicht "nur" um eine Candle ab (was eigentlich auch schon bedenklich stimmt).

Hab mir den Master jetzt nochmal angeschaut und folgendes Problem/Fehler entdeckt:

Die ROC Berechnung in der Originalform geht von positiven Werten aus. Da wir hier aber auch negative Werte haben können (Steigung der Equity) muss man die ROC Formel ein bissl anpassen.

 

Original:

roc= slope/last_slope -1

Allgemeine Variante (funktioniert auch für negative Werte):

roc= (slope - last_slope)/MathAbs(last_slope)

 

Es stellt sich jetzt natürlich die Frage ob bei dieser Berechnung die ROC in der Form Sinn macht. Der Slope schwankt ja um 0. Ist jetzt eine Änderung der Steigung der Equity von 0.2 auf 0.4 wirklich doppelt soviel wie eine Änderung von 1 auf 1.5 ? In relativen Zahlen ja, aber macht das in diesem Zusammenhang Sinn?

Bzw. ist eine Änderung von -0.1 auf +0.1 gleichviel "Wert" wie eine Änderung von 0.5 auf 1.5 ?

@Mythos

Vielen Dank für die Überarbeitung. Mir wäre dieser Fehler gar nicht aufgefallen.

 

Eigentlich ist es egal, wie stark sich die ROC ändert. Idee des Masters ist es ja, sich das aktuelle Gewinnersystem zu schnappen und dem zu folgen. Dass er nicht wie wild hin- und herflattert soll durch die Glättung der Equity, Slope, etc. vermieden werden.

 

Bin ja mal auf den neuen Master (neues ROC, Open Bars) gespannt. Selbst den Fehler behafteten konnte ich ja zur Verbesserung der Subsysteme hinprügeln .

Eigentlich ist es egal, wie stark sich die ROC ändert. Idee des Masters ist es ja, sich das aktuelle Gewinnersystem zu schnappen und dem zu folgen.

 

Stimmt, da alle Subsysteme mit gleicher Positionsgröße arbeiten und es ja nur 2 Entscheidungen im Markt gibt, sollte es sich nicht auswirken. Wenn die "richtige Richtung" ein ROC > 0 produziert, muss die "falsche" automatisch einen ROC

Denke ich auch - wird aber ja eh der Test zeigen .

Packst Du die neue Datei dann hier in den Thread oder wo kann man die dann finden? Bzw. was muss man neben der ROC ändern, damit er auf Bar Open agiert?

Packst Du die neue Datei dann hier in den Thread?

 

Hoppla, wollts eigentlich vorher schon dazupacken. Hier der neue Master:

eSystemOfSystems.mq4

 

Wirklich geändert hat sich wie gesagt nicht viel. Die ROC-Berechnung im getDirection und das lastTime im start() als Einschränkung aufs Bar-Open.

 

Ich hab gleich noch den SlopeFilter dazugebaut, setzt man den auf true muss die slope positiv sein, damit das subsys als "gut" gewertet wird.