Projekt: Entwicklung Community-EA

[Mythos]

Nachsatz zu : Es muss natürlich sinnvoll sein, wenn das Anfertigen des LH länger braucht, als das Schreiben der Include ....aber indirekt hatten wir das ja schon oben . Egal ... wenn ich was helfen kann, dann sehr gerne . Lobo

 

Jup, hilfe ist jederzeit willkommen ;) ich würde es nur (im Sinne des "bei 0 starten") vorerst nicht in includes auslagern sondern die erste Version in einem File machen. Darauf aufbauend kann man dann ja "den Werdegang beim programmieren" in gewisser Weise dokumentieren indem man Errorhandling fürs Ordermanagement dazupackt (und dann in library auslagert/die TB einbindet), module in eigene Files auslagert etc.

 

Ich möchte nur den anderen auch noch Gelegenheit geben ihre Meinung zu dem Vorschlag abzugeben (und ich bin die letzten tage auch zu nix gekommen ;). sobald die start() dann steht, gibt des im Prinzip die verschiedenen "Lastenhefte" für die einzelnen Funktionen/Module, aber das kommt dann.

[Der Wolf]

Hallo,

ich habe mir die TradeBox-Library-Funktionen angesehen, das gefällt mir sehr gut, da hat sicherlich eine Menge Arbeit drin gesteckt !

 

Danach habe ich mir mal die Codingconvention's und die drei verschiedenen Varianten zum EA-Grundgerüst angsehen. Die Variante "eTomNextBausatz" sieht doch ganz gut aus, denke das wäre ausbaubar !

 

Um mich mit den TradeBox-Funktionen näher zu beschäftigen habe ich aus der Struktur eines einfachen Metaquotes-Sample-Programm (MovingAverage.mq4, den habe ich in einem "MQL4 Reference Guide.pdf" gefunden) einen EA gebastelt. In diesem EA (den habe ich WolfsTestEATradeBox genannt) will ich für mich die TradeBox-Funktionen testen.

 

Ich habe versucht, mich an die Codingconvention's und teilweise an die Struktur von "eTomNextBausatz" anzulehnen.

Den EA stelle ich mal so rein, er ist nur notdürftig getestet, da er erst in den vergangen zwei Tagen - naja eher Nächten - entstanden ist. Habe nur einen MovingAverage als Filter und ChandelierExit bzw. ParabolicSAR eingehängt, also Einstiegssignale existieren noch nicht !

 

Lauffähig ist das Ganze, ich lade einen StrategyReport der vergangen Woche (24.10.-28.10.2011) für den EURUSD M15 hoch.

 

@Mythos

Wenn die Struktur des EA's gefällt, vielleicht könnte es eine Grundlage für die weitere Entwicklung des Community-EA sein ?

 

Wenn nicht, dann bastel ich halt weiter im stillen Kämmerlein so vor mich hin und werde die TradeBox-Funktionalitäten nach und nach einbauen und testen.

 

Ein schönes Wochenende wünscht Euch, Der Wolf !

WolfsTestEATradeBox.mq4

StrategyTester.EURUSD.M15.2011.10.24_2011.10.28.htm

[Lobo.Trader]

dann bastel ich halt weiter im stillen Kämmerlein so vor mich hin

 

Genau das solltest Du besser nicht machen, dass mache ich schon lange Zeit und renne mich immer wieder mal fest . Allerdings arbeite ich parallel , indem ich einerseits hier bereit zur Mitarbeit stehe und ansonsten aufmerksam mitlese . Und parallel arbeite ich an meinem Project weiter .

 

Freut mich aber, dass auch Dir die Box von Mythos gut gefällt, sie erspart demjenigen der sich einmal darin einarbeitet sehr viel Zeit !!

 

Lobo

 

EDIT : PS : Muss #import nicht zweimal kommen, zum Beginn und zum Abschluss der Fkt.-Def. ? S.a. External functions definition

 

#import "user32.dll"
 int     MessageBoxA(int hWnd ,string szText,string szCaption,int nType);
 int     SendMessageA(int hWnd,int Msg,int wParam,int lParam);
#import "lib.ex4"
 double  round(double value);
#import

Edited November 4, 2011 by Lobo.Trader

[Der Wolf]

@Lobo

"Genau das solltest Du besser nicht machen ..."

Das war doch nur ein kleiner Spaß, ich bastel unabhängig von dem Projekt hier an meinem eigenen EA, bin hier dankenderweise auf die TradeBox gestossen, deren Funktionen ich somit nebenbei antesten werde, und für die Community fällt vielleicht auch noch was ab ?!

 

"Muss #import nicht zweimal kommen, zum Beginn und zum Abschluss der Fkt.-Def. ?"

Sehr aufmerksam, danke ! Soll so sein, ich hab's schon geändert und bei mir im ChangeLog dokumentiert. In Verson 0.11 ist's drin.

Der Compiler hat's aber problemlos geschluckt, es gab keine Warning !

[Mythos]

Hi,

 

bin leider gerade etwas eingeteilt und habs nur "überflogen", aber sieht nett aus. Einen Anfänger schreckt es sicher schon ein bissl ab, aber ich befürchte das werden wir nicht verhindern können. Dafür müssten wir wirklich bei fast leerem File starten.

 

@Wolf: Vielleicht könnten wir die Infomaschinerie (also das logging) derweil noch rausnehmen? Ist die Struktur jetzt vorbereitet auf die beschriebene Logik? Magst du vielleicht kurz den Ablauf erklären? Die start() is ja sehr spartanisch. Welche Funktion tut was, wie ist der grobe Programmablauf? Da du hier schon recht weit in der Implementierung bist, wärs dann sicher für andere Coder leichter einzusteigen.

 

Was meinen die anderen?

 

@#import: formal muss es danach nochmal kommen, aber der compiler kommt mit beidem klar.

[RAiNWORM]

Wenn die Struktur des EA's gefällt, vielleicht könnte es eine Grundlage für die weitere Entwicklung des Community-EA sein ?

Ich habe mir den Quellcode nun mal sorgfältig durchgelesen. Zunächst muss ich sagen, dass ich mit deinem Coding-Stil gut zurecht komme. Ich finde das ein sehr brauchbares Grundgerüst. Vielleicht hast du Anfänger damit aber schon lange abgehängt (z.B. return-Wert durch call by reference im calcExitSignal).

 

Nun aber gleich was zum Code:

In der Funktion lotsOptimized verringerst du offensichtlich die Lots in Abhängigkeit der aufeinanderfolgenden Verluste. Das sollten wir inhaltlich nochmals mit allen diskutieren, aber darum geht's mir jetzt nicht. Vielmehr iterierst du über die For-Schleife rückwärts durch die Trade-History. Die Reihenfolge der History ist jedoch willkürlich, bzw. nicht garantiert. Das heißt, sie muss nicht zwangsläufig chronologisch sortiert sein. Ich meine mal festgestellt zu haben, dass die Sortierreihenfolge der Darstellungsreihenfolge (also die in der Applikation dargestellten Tabelle im MT4) entspricht. Selbst eine Filterung dieser Tradehistory hat m.W. Auswirkung auf den OrderSelect(...,MODE_HISTORY).

Eigentlich müsste man sich - um ganz sicher zu gehen - eine Funktion schreiben, welche die History als chronoligisch sortierte Liste zurückgibt.

 

Im checkForOpen fehlt mir persönlich noch eine Prüfung der Umgebungsparameter. Damit meine ich bspw. "Sonntags nicht traden", "kein Trade am Freitag nach 20:00 Uhr", "Gesamtportfolio-Risiko (über alle Symbols)

[Lobo.Trader]

Einerseits ist es schön, dass Wolf nun schonmal seinen EA hier platziert hat anderseits besagt der Titel des Threads , dass wir den EA als Communitiy entwickeln wollen . Insofern weiss ich nicht, ob wir hier jetzt nen Strich ziehen und sagen " " ?

 

Oder wollen wir weiter zusammen arbeiten ? Wolf, was schlägst Du denn nun vor .. wie machen wir weiter oder sind wir fertig ?

 

 

Mir fehlt (für mich aber nur) mein Flussdiagramm, dann das Aufgliedern der Funktionen, planen der Variablen ...alles was man so macht, wenn man strukturiert und später für andere nachvollziehbar , vorgehen will .

 

Lobo

Edited November 5, 2011 by Lobo.Trader

[Mythos]

Also ich seh es weiterhin als Gemeinschaftsprojekt.

Es stimmt, Wolf hat sehr viel allein gemacht, da besteht die Gefahr das es mehr zu "seinem EA mit unseren Anmerkungen" wird.

Was is euch lieber: Wolfs EA-Grundgerüst erweitern oder echt komplett bei 0 starten und langsam gemeinsam aufbauen?

 

Wie gesagt, für Anfänger und stille Mitleser ist ein dokumentiertes langsames von 0 weg sicher optimal. Das dauert halt dementsprechend lange bis es dann wirklich fertig ist.

 

Wir können es auch teilen, hier bleibt der "Public learning"-teil wo der EA langsam von 0 aufgezogen wird, wer es eilig hat, kann sich mit Wolf an "seiner" Variante beteiligen. (Würde dafür einfach die entsprechenden Posts auslagern, sofern gewünscht). Damit besteht nur das Risiko das sich die (jetzt schon überschaubare) Anzahl der Mitentwickler halbiert...

[Lobo.Trader]

(jetzt schon überschaubare) Anzahl der Mitentwickler halbiert...

 

Jau, auch aufgefallen .

 

Wollen wir nicht den schönen EA von Wolf nehmen und die "Theorie" die fehlt (das Grundgerüst) nachträglich anfertigen ...so eine Art "Diskusion des Wolf-EA" . Da sind ja interessante Dinge enthalten, die man noch ein wenig erarbeiten kann . Dann können wir die Code-Segmente herausziehen, die die einzelnen Punkte des "Lastenheftes" erfüllen .

 

Auf diese Weise nutzen wir die von ihm bereits geleistete Arbeit und können diesen Thread dann vgls schnell zu einem Abschluss führen, der aber dann auch weiteren Generationen Coder helfen kann ?

 

Lobo

[Lobo.Trader]

@Wolf , vielleicht hast Du ja sogar vorher etwas skiziert ? Flussdiagram o.ä. ?

 

@Rainworm : "... durch call by reference im...." was bedeutet dieser Begriff ? Ist das eine Form der indirekten Adressierung ? Hast Du einen Link dazu ?

 

bool calcExitSignal(double& ref_stop, int cmd, double price)

 

Oder hat es etwas mit dem "double&" zu tun ?

 

Lobo

[RAiNWORM]

Wir könnten beide von Mythos vorgeschlagene Varianten kombinieren: von vorne Anfangen und Wolfs EA durchsprechen. Das heißt, wir beginnen vorne (bei start()), nehmen uns den vorhandenen Programmteil und sprechen diesen Schritt für Schritt durch. Dabei kann es natürlich passieren, dass das bereits Vorhandene im Nachgang ganz anders umgesetzt wird. Fände ich nicht weiter schlimm, so lange es besser wird.

 

@Rainworm : "... durch call by reference im...." was bedeutet dieser Begriff ? Ist das eine Form der indirekten Adressierung ? Hast Du einen Link dazu ?

bool calcExitSignal(double& ref_stop, int cmd, double price)

Oder hat es etwas mit dem "double&" zu tun ?

Ja, das "double&" bedeutet, dass die übergebene Variable "by reference" und nicht "by value" übergeben wird. Im Normalfall (also, "by value", also ohne das &-Zeichen), hat die Veränderung der Variable ref_stop innerhalb der Funktion keine Auswirkungen auf die aufrufende Funktion. So, wie es hier gemacht wird, gibt die Funktion nicht nur einen Wert per return zurück, sondern auch über die veränderte Variable ref_stop.

 

Beispiel:

Ich rufe aus start() Funktion calcExitSignal wie folgt auf:

Rueckgabewert = calcExitSignal(stop, OP_BUY, 1.32)

 

Vor dem Aufruf hat die hier verwendete Variable stop vielleicht den Wert 1.1. Allerdings wird der Wert von stop durch die Funktion calcExitSignal angepasst, sodass sich nach dem Aufruf nicht nur Rueckgabewert, sondern auch stop geändert haben wird.

 

Technisch wird bei "call by reference" nämlich nur die Speicheradresse und nicht der Wert übergeben.

 

Siehe auch: http://abraham.fh-lausitz.de/profs/robel/faq/callByReference.html

[Lobo.Trader]

@Rainworm : ... im Sinne dieses Threads ein weiterer Link , der ebenfalls sehr schöne Erklärungen völlig kolo zur Verfügung stellt : PeaceSoftware_C-Kurs

 

 

von vorne Anfangen und Wolfs EA durchsprechen.... nicht weiter schlimm, so lange es besser wird.

 

 

Können uns ja nun wirklich auch Zeit lassen ...

 

Lobo

[Der Wolf]

Hallo zusammen,

sorry, ich habe heute den schönen Sonnenschein zu einem Spaziergang genutzt, bin gerade erst heimgekommen und sehe etliche Reaktionen auf den Code, den ich gestern hier als Vorschlag eines Gundgerüst's eingestellt habe. Ich danke Euch erstmal für Eure Antworten !

 

Ich verspreche Euch, ich werde jede Eurer Fragen beantworten, auch zumindest eine Kurz-Doku zum Code liefern.

Ich fang schon mal an, Wölfe sind nunmal nachtaktiv, die Nacht hat gerade erst angefangen, ihr hört wieder von mir !

Gruß, Der Wolf

[Mythos]

Ich verspreche Euch, ich werde jede Eurer Fragen beantworten, auch zumindest eine Kurz-Doku zum Code liefern.

 

gern.

 

Ansonsten find ich den Vorschlag von Rainworm gut. Am besten immer den besprochenen Teil direkt als Code einbinden. Einerseits damit man nit zuviel auf einmal angeht, andererseits damit jeder weiß um was es geht ohne den Code parallel offen zu haben und rumscrollen zu müssen.

[Der Wolf]

@RAINWORM

"lotsOptimized"

die Funktion lotsOptimized stammt noch vom DemoEA !

Die Funktion kann also komplett weg und sollte durch was eigenes ersetzt werden.

 

"Im checkForOpen fehlt mir persönlich noch eine Prüfung der Umgebungsparameter."

bitte, eine Funktion "checkEnvironmentParameters()" ist schnell in checkForOpen() eingehängt. In dieser Funktion könntest Du dann alles berücksichtigen.

 

 

@Lobo

"Oder wollen wir weiter zusammen arbeiten ?"

@Mythos

"Es stimmt, Wolf hat sehr viel allein gemacht, da besteht die Gefahr das es mehr zu "seinem EA mit unseren Anmerkungen" wird."

@Lobo + @Mythos

Ich will Euch mein Gerüst nicht aufdrängen, aber nachdem da kein anderer mit einer Struktur vorgeprescht ist, und die Woche fast um war, habe ich halt meinen TestEA hochgeladen und zur Diskussion gestellt.

 

Ich denke das Ganze muss sich erst etwas setzen.

Wenn ihr den Code durchdiskutieren wollt, ist das ja schon ein sehr guter Ansatz, ich werde Euch da unterstützen.

Einfach fragen !

 

So, jetzt mach ich mal meinen Sonntagnachmittagsspaziergang.

Einen schönen Sonntag wünscht Euch, der Wolf

[Der Wolf]

Und hier noch eine kleine Kurzdokumentation:

 

Ich fang mal mit start() an:

Der Aufruf von calculateCurrentOrders() gibt einen Zähler von eventuell vorhandenen offenen Positionen zurück.

Ist der Zähler 0, dann kann in checkForOpen() geprüft werden, ob ein Einstieg erfolgen kann.

Ist der Zähler größer 0, dann kann in checkForClose() geprüft werden, ob die Order geschlossen oder der Stoploss verändert werden kann.

Mehr sollte meines Erachtens nicht in der start()-Funktion stehen.

Alle zukünftigen Erweiterungen (wie z.B. checkEnvironmentParameters() ) sollten dann in den entsprechenden Kontext eingehängt werden, also eine eventuelle Prüfung auf Umgebungsparameter dann in checkForOpen.

 

Was macht checkForOpen:

es ruft nacheinander calcFilterSignal und calcEntrySignal auf. Zukünftig dann auch noch checkEnvironmentParameters().

Und wenn die Signale alle in eine Richtung zeigen, dann wird erst der initiale Stop errechnet und eine Order eröffnet.

 

Was macht checkForClose:

es ruft calcExitSignal auf. Dort befindet sich die Logik, wann die Order explizit geschlossen wird.

Der Wert des ermittelten Stoploss wird als Referenzparamter an checkForClose zurückgegeben, damit anschliessend der Stoplosss mittels ModifyOrder geädnert werden kann.

Anstelle einer Rückgabe des Stoploss als Referenzparameter könnte man alternativ auch zuallererst den Stoploss ermitteln und diesen dann als Valueparameter an calcExitSignal nach unten reichen. Dann sollten auch Anfänger damit klarkommen.

 

In init() wird durch Aufruf von calcHigherTimeframe() der übergeordnete Timeframe errechnet.

Das passiert aber nur einmal, da die Variable higher_timeframe static ist !

Anschliessend werden die Längen des kurz- und des langfristigen Filters festgelegt.

Das kann man auch anders machen, einfach fix per externem Parameter vorgeben.

 

Das wars auch schon zum Block mit den "basic functions".

Alle Unterfunktionen habe ich unter "auxiliary functions" gruppiert.

Und dann gibt es noch einen Block mit "filter functions", naja bis jetzt ist da nur eine drin, aber es können ja noch mehrere

Filter dazukommen.

Und die "indicator functions" sollten natürlich auch mehr werden.

 

Ich denke für's erste reicht das mal.

[Mythos]

Danke Wolf für die Erklärung. Aber ich glaube wenn wir es weiter in dem Stil machen (Du erklärst uns was im EA passiert), ist es endgültig nur dein EA und wir kommentieren.

 

Damit es ein Gemeinschaftsprojekt bleibt, sollten wir es in der Gruppe Schritt für Schritt durchackern und hinterfragen. Es geht ja nicht hauptsächlich darum zu verstehen was der EA tut, sondern eher darum das wir einen EA bauen wo alle mitbestimmen wie es gemacht wird. In dem Sinn ist der EA eigentlich eine implementierte Version "deiner Meinung" (und als solches auch sehr gut), jetzt fehlt halt die Meinung der anderen.

 

Also langsam und Schritt für Schritt.

 

Aus meiner Sicht erster Punkt in der Implementierung: Was kommt in die start()? Wolf zeigt uns einen sehr spartanischen Ansatz. Aus meiner Sicht ist es sehr vorteilhaft für die Modularisierung und damit schnelle austauschbarkeit von Teilen, wenn man logische Komponenten in eigene Funktionen packt. Für mich müsste es nicht ganz so extrem aufgeräumt sein wie bei Wolf, kann aber ;)

 

Hier der Code:

void start()
{
//---- 
  if(Bars<100 || !IsTradeAllowed()) 
    return;
  if (!EachTickMode && !isNewBar()) 
    return;       
  if(calculateCurrentOrders(Symbol())==0) 
     checkForOpen();
  else 
     checkForClose();
//----
}

 

(@Wolf: hab ein bissl was angepasst da du bei den Namensbezeichnungen nit ganz einheitlich warst )

Schritt für Schritt:

- wenn zuwenig Bars vorhanden oder traden nicht erlaubt -> tu nix (return)

- wenn wir nicht jeden Tick überprüfen und es ist kein neuer Bar-> tu nix

Dann kommt die eigentliche Tradingthematik:

- gibt es offene Orders? wenn ja: checkForClose() sonst: checkForOpen().

 

Meine Anmerkungen (wenn man so aufgeräumt arbeitet):

- ich würde IsTradeAllowed gleich erweitern auf eine eigene Funktion wo man Zeitabhängige Filter etc einbauen kann.

- ich würde checkForClose() in handleOpenOrders() umbenennen und immer aufrufen. Damit wird der EA auch multipleOrder-fähig und es passt von der Bezeichnung her besser. checkForClose() schließt ja nicht nur sondern zieht auch stops nach etc. (sollte es zumindest).

- weiters würde ich die Abfrage ob Orders offen sind und ob dann getraded werden darf in das eigene isTradeAllowed() packen.

- das handleOpenOrders() sollte man nicht mit den gleichen Beschränkungen (nur neuer Bar etc) ausführen wie das checkForOpen(), es kann ja Zeitfilter etc. geben die innerhalb des Bars aktiv werden und dann auch aktiviert werden sollten. (oder wenn man dann später den Stop nicht mehr an den Broker sendet sondern selber verwaltet, dann muss man bei jedem Tick überprüfen)

 

Also nach der groben Logik:

- verarbeite offene Orders (stopnachziehen, schließen whatever) (ob vor oder nach dem eröffnen ist dann eine Detailfrage, in der Form ist man schneller im Trendwechsel wenn nur gleichgeschaltete Orders erlaubt)

- ist es gerade erlaubt neue Orders zu eröffnen? wenn ja: checkForOpen()

 

codemäßig:

void start()
{
  handleOpenOrders();
  if(isTradeAllowed()) 
    checkForOpen();
}

bool isTradeAllowed() {
  if (!EachTickMode && !isNewBar()) 
    return false;       
  if(Bars<100 || !IsTradeAllowed()) 
    return false;
  if(calculateCurrentOrders() < MaxOpenOrders) 
    return true;
  else
    return false;
}

 

Das isTradeAllowed implementiert also die Logik "Dürfte ich bei dem Tick eine neue Order eröffnen" unabhängig von Signalen etc. Wie gesagt, nur für die eröffnung, die Verarbeitung bereits offener Orders ist mMn ein ganz anderes (unabhängiges) Thema und sollte deswegen auch unabhängig implementiert werden.

 

soweit meine 2 cent ;)

 

Nochwas zum Ablauf: Wenn wir wirklich gemeinsam alles durchgehen wollen, müssen wir uns glaub ich wieder auf einzelne Bereiche beschränken und derweil die anderen Themen außen vorlassen, wenn wir jetzt gleichzeitig über mehrere Funktionen diskutieren und parallel noch neue features vorschlagen, verliert sich das Ganze.

[mtbf40]

Hallo Leute,

 

macht doch nicht den 3. Schritt vorm 1. und den zweiten vorm 4. etc.

 

Fangt doch mal mit einem Struktogramm an, damit jeder der hier einsteigt/einsteigen will auch einen Einstiegspunkt hat!! Ich würde auch einen Teil programmieren, habe aber nicht die Zeit mir jeden Einzelschritt, der bisher gemacht wurde, anzuschauen. Wenn ein Struktogramm oder Programmablaufplan existieren würde, könnte man die Arbeiten auch besser verteilen. Denn der EA sollte ja, wie bisher besprochen, modular aufgebaut werden... und dann wäre es ja auch niocht der EA von Wolf sondern der Community-EA

 

schönen Sonntag mtbf40

[Mythos]

Fangt doch mal mit einem Struktogramm an, damit jeder der hier einsteigt/einsteigen will auch einen Einstiegspunkt hat!! Ich würde auch einen Teil programmieren, habe aber nicht die Zeit mir jeden Einzelschritt, der bisher gemacht wurde, anzuschauen. Wenn ein Struktogramm oder Programmablaufplan existieren würde, könnte man die Arbeiten auch besser verteilen.

 

Aus meiner Sicht gibt es 2 Möglichkeiten:

1. Wir schauen das wir möglichst schnell und effizient einen fertigen EA haben.

2. Wir versuchen es auch als "Schauentwicklung" für Anfänger/Mitleser zu gestalten.

 

Im 1. Fall wär der nächste Schritt: Aufteilung und Definition einzelner Module, Verteilung der Aufgaben an Entwickler. Zusammenbauen und testen. Damit wär der EA schnell fertig, aber jeder Entwickler hat nur seinen eigenen Code "verstanden" und öffentlich präsentiert und durchgearbeitet wird überhaupt nix weil zulange dauert etc.

 

Im 2. Fall "müssen" wir jeden einzelnen Schritt durchkauen und erarbeiten. Ja das dauert länger, aber damit kann jeder Anfänger was damit anfangen.

 

Zum Struktogramm und Modulaufteilung: Eigentlich gibts die Modulaufteilung ja schon in Post #171.

Wer gern ein Struktogramm dazu machen will, ist herzlich eingeladen. Oder fehlt noch eine Information?

[Mythos]

Hier mal ein textuelles Struktogramm wie ich mir den groben Ablauf des EA vorstellen könnte. Textuell deshalb weil man so einfach einzelne Abschnitte zitieren kann und nit immer in einer Grafik rummalen muss. Außerdem ist der Komplexitätsgrad noch niedrig genug das man nit mehr braucht. Wer mag darf gern eine schöne Grafik daraus machen ;)

 

Ebene1 (start())

 

- Verarbeitung offener Positionen

? Eröffnung neuer Orders erlaubt?

+ JA: Überprüfe auf Signal

+ NEIN: Nix.

 

Ebene2 (aufgerufene Funktionen/Module)

 

Verarbeitung offener Positionen:

Für alle offenen Positionen

- ziehe TrailingStop/Breakeven nach

? Position aufgrund von Timeout zu schließen?

+ JA: schließe Pos und geh zur nächsten.

? Position aufgrund von Zeitfilter zu schließen?

+ JA: schließe Pos und geh zur nächsten.

 

Eröffnung neuer Orders erlaubt:

? Wurde dieser Bar bereits überprüft?

+ JA: return false;

? Außerhalb der erlaubten Handelszeiten?

+ JA: return false;

? Anzahl der maximal gleichzeitigen Orders bereits erreicht?

+ JA: return false;

- return true;

 

Überprüfe auf Signal:

- Berechne Signalrichtung (SHORT, FLAT oder LONG)

- Berechne Filterrichtung (SHORT, FLAT oder LONG)

? Sind bereits Positionen offen?

+ JA: Ermittle Richtung dieser Positionen

? Sind Richtung von Signal und Filter unterschiedlich (oder Signal flat)?

+ JA: return

? Ist Signalrichtung ungleich der bestehenden Positionen und keine gegensätzlichen Positionen erlaubt?

+ JA: return

- Berechne InitStopentfernung

- Berechne Positionsgröße

- Berechne TPentfernung

- Öffne Position

 

Aus meiner Sicht wären die fetten Punkte mögliche Module die (als eigene Funktionen) man separat entwickeln kann (Der Vollständigkeitshalber: Was die Module machen ist in Post #171 beschrieben). Dafür müsste aber einerseits erstmal die aufrufende Struktur stehen, anderseits sprechen die schon genannten Gründe des public learnings gegen die parallele Entwicklung der Module.

 

Wie schon gesagt, wenn sich genug finden die den EA "schnell" bauen möchten, kann man es in ein eigenes Thema ausgliedern. Hier haben wir uns (soweit ich das sehe) darauf geeinigt defakto bei 0 zu starten und den gesamten Prozess Schritt für Schritt durchzukauen. Hier soll dieses "Struktogramm" in erster Linie zur groben Orientierung dienen.

 

Gibts Meinungen zur Struktur/Ablauf? (Ich freu mich auch über ein "is ok so" ;)

[Der Wolf]

Hier haben wir uns (soweit ich das sehe) darauf geeinigt defakto bei 0 zu starten und den gesamten Prozess Schritt für Schritt durchzukauen.

Finde ich sehr in Ordnung !

 

- das handleOpenOrders() sollte man nicht mit den gleichen Beschränkungen (nur neuer Bar etc) ausführen wie das checkForOpen(), es kann ja Zeitfilter etc. geben die innerhalb des Bars aktiv werden und dann auch aktiviert werden sollten. (oder wenn man dann später den Stop nicht mehr an den Broker sendet sondern selber verwaltet, dann muss man bei jedem Tick überprüfen)

Eine sehr gute Idee !

 

@RAINWORM

Danke für Deine Erläuterungen zu "call by reference" !

 

@Wolf , vielleicht hast Du ja sogar vorher etwas skiziert ? Flussdiagram o.ä. ?

Nein, ich habe da nichts weiter gemacht.

 

Der Vollständigkeit füge ich noch die Sample-Datei bei, auf deren Struktur ich meinen Test-EA aufgebaut habe.

Sample_MovingAverage.txt

[Licens]

Ich freu mich auch über ein "is ok so" ;)

 

Is ok so.

[Lobo.Trader]

"is ok so"

 

Ja, is ok so , mehr als das, zumindest mir hilft das auch in der Zukunft .

 

Dafür möchte ich mich bei allen, besonders aber bei Mythos und beim Wolf recht herzlich bedanken .

 

Wenn ich jetzt die Konventionen #171 , den #196, den #192 als Konzept und schlussendlich den eigentlichen EA Post #177 in dieser Reihenfolge lese, dann kann ich als Einsteiger eine Menge von Euch lernen (vielleicht sollte man diese 4 Post auch als eine Einheit irgendwo "zentral" und mit passenden Titel für das Suchen platzieren ? ) .

 

Viele Grüße, nochmals ein dickes Danke von mir

 

 

Lobo

[Der Wolf]

dann kann ich als Einsteiger eine Menge von Euch lernen ... ein dickes Danke von mir

Gerne, freut mich, man lernt nie aus !

Gruß, Der Wolf

[Mythos]

Kurzes Lebenszeichen. Letzte Woche war ich (leider) beruflich durchgehend unterwegs und eingeteilt, wodurch i zu nix gekommen bin und das Wochenende wird vermutlich auch ohne Internetzugang verlaufen, von mir kommt hier also frühestens nächste Woche wieder ein Beitrag.

 

Gibts sonst Kommentare zur start() oder sollen wir dann im Code weitergehen?