An einfachsten wär es wohl, wenn jemand ein Grundgerüst zur Verfügung stellen würde.

 

Das ist eine gute Idee. Ich würde die Erstellung eines solchen fast in ein eigenständiges Projekt auslagern. Schließlich dürften sich viele Neulinge über ein Grundgerüst freuen mit dem sie experimentieren können.

super, bin gespannt, mal was von anderen Codern zu sehen

Also dann, hier mal mein Vorschlag.

 

Das Gerüst ist von Mythos. Ich hab ein klein wenig formatiert und die Teile, die für MM, Signalgenerierung und SL-Handling

nötig sind, in Libraries ausgelagert.

 

Zum Testen hab ich eine einfache Strategie implementiert.

 

• läuft auf H1
  
• handeln nur in Richtung eines Filters, der in einer zusätzlichen Library ist und einen NonLagMA als Kriterium hat
  
• Einstieg nur möglich, wenn Vortageskerze nahe am Hoch/Tief geschlossen hat (Prozentsatz einstellbar per Parameter)
  
• Einstieg dann, wenn auch die letzte abgeschlossene Stundenkerze nahe an ihrem Hoch/Tief geschlossen hat
  
• Einstieg nur möglich bis zu einer best. Tageszeit.
  
• Einstieg nur möglich, wenn die D1-Kerzenrange grösser als die durchschnittliche ATR der letzten Tage ist
  
• Position wird über einen fixen TP oder beim Erreichen einer best. Tageszeit geschlossen.
  
• SL wird als einfacher Trailingstop immer einen best. Wert unter/über der Vorstundenkerze gesetzt
   
  

Die Strategie hab ich wirklich nur eingebaut um das Grundgerüst testen zu können und ist schnell wieder rausgeschmissen.

Auch das SL-Handling ist mehr oder weniger nur ein Dummy.

 

Ich will jetzt eigentlich garnicht zuviel dazu schreiben. Es sollte alles noch sehr einfach sein. Ich hab mir zumindest Mühe gegeben, das alles nicht schon am Anfang zu kompliziert zu machen.

Die einzelnen Funktionalitäten sind sehr modular aufgebaut und können mMn eigenständig weiterentwickelt werden.

Ich hab versucht alles einigermassen zu kommentieren, wenn auch teilweise in Englisch, teilweise auf Deutsch. Das ist noch unschön. Sollten wir uns mal abstimmen, wie wir das halten wollen.

 

Im Zip-File anbei ist alles, was nötig ist um das Ding zum Laufen zu bringen. Die Libraries (beginnen alle mit lib...) in's libraries Verzeichnis kopieren und den Indikator ins... (na wohin wohl? ).

 

Ich hoffe, ihr findet, das Ganze taugt was als Basis.

 

eTomNextBausatz.zip

Ich hoffe, ihr findet, das Ganze taugt was als Basis.

 

klar, bischen umgewöhnen und dann geht´s. Aber logisch sehr gut aufgebaut mal ein bischen experimentieren damit um ein Gefühl dafür zu bekommen!!

klar, bischen umgewöhnen und dann geht´s.

Nicht bös gemeint, aber so ersparen sich alle das doppelt lesen und der Thread bleibt kürzer...

 

Zitieren

Zum Testen hab ich eine einfache Strategie implementiert.

Ich würd vorschlagen/bitten, das es sich hier bei den hochgeladenen Varianten immer nur um das Grundgerüst selber handelt. Wenn man zum testen ein kleines System reinimplementiert, kein Problem. Man könnte es zB einfach auskommentieren und mit dem Hinweis "Hier kommt SL-Logic hin, wie zum Beispiel:" versehen. Aber am liebsten wär mir wenn der Code wirklich ein "sauberes" Gerüst wird.

Ich stell mir gerade einen Neuling vor, der das in die Finger kriegt und denkt er probiert mal rum. Der muss erstmal rausfinden was ist Testsystem und was ist für die Funktionalität des Gerüsts notwendig, und das würde ich ihm gern ersparen.

 

An sich find ichs recht gut, bei mir siehts nur aufgrund der Tabs ein bissl durch den Wind aus.

Zur StopLoss Function etc.: War nicht geplant eine SL-Function im EA die dann auf die gewünschte Funktion aus der Lib verweist (So wie beim entrysignal und TP)? Weil so müsste man der Lib-Funktion immer alle möglichen Parameter mitgeben (die man gar nicht bräuchte) + dem Parameter was jetzt eigentlich passieren soll. Eine Lib is ja nit gedacht um geändert zu werden.

 

Und noch ne Frage (sorry wenn ich zu kritisch bin): Du hast in jeder Lib die Funktion PointX, es gibt die exakt gleiche Funktion auch schon in der TB, machts Sinn die überall neu zu definieren?

 

Nicht das es falsch rüberkommt: Ich freu mich sehr über das Projekt und die rege Beteiligung

Nicht das es falsch rüberkommt

Natuerlich nicht. Es soll ja ein Projekt sein, wo jeder auch offen und ehrlich seine Meinung sagen soll.

 

Du hast natuerlich recht. Die Struktur mit sovielen Libraries hat einige Nachteile. In einem eigenen EA wuerd ich das auch nicht so machen. Der Hintergedanke war ganz einfach, wenn mehrere Leute unterschiedliche Funktionalitaeten bearbeiten wollen, dann ist auf diese Weise die Aufteilung am einfachsten. Das Beispiel hab ich nur drin gelassen, weil ich denke, dass somit der Code am einfachsten zu verstehen ist. Das fliegt dann natuerlich wieder raus...

 

Das mit den Tabs/Einrueckungen ist natuerlich unschoen. Je nach verwendetem Editor (ich benutze UltraEdit) sind die Vorschuebe jeweils anders.

Zu PointX ist mir ehrlich gesagt nichts besseres eingefallen. Sonst muesste ich ja in jede Lib die Tradebox als Lib includieren, oder gibt es da ne elegantere Loesung?

Wie sieht es denn mit einem Abschnitt aus, der die allgemeinen Rahmenbedingungen prüft, bevor überhaupt ein Entrysignal zu einer Order führt? Ich nutze bei mir gerne so etwas:

 

 // -- check common conditions --
if (!IsDemo()) // real account 
{ 
 if (AccountFreeMargin() < __dFreeMargin) return; // minimum free margin
 if (get_spread()        > __dMaxSpread)  return; // current spread

 double dDayProfitLoss = get_day_profit(true);
 if (dDayProfitLoss    > __dMaxDayProfit) return; // maximum profit per day reached
 if (dDayProfitLoss    < __dMaxDayLoss)   return; // maximum loss per day reached
}
if (TimeDayOfWeek(Time[0]) == 0)          return; // no trade on sunday

double dPortfolioVAR = get_var();
if ((dPortfolioVAR/ AccountBalance()) > __dMaxPortfolioRisk) return; // cumulated portfolio risk too high

 

Die Prüfungen sind (auf deutsch):

• freie Mindestmargin
  
• maximaler Spread
  
• Maximaler Tagesgewinn
  
• Maximaler Tagesverlust
  
• Handels-/Tageszeiten
  
• Gesamt-Portfolio-Risiko
  

Ich deute das Vergeben von Thanks als Zustimmung und habe obige Prüfungen implementiert. Das Gesamt-ZIP ist im Anhang. Bitte bei einem 5-Digit-Broker prüfen und ggf. anpassen!

 

@Admins: Übrigens stimmt etwas mit der Download-Anzahl-Anzeige nicht. Den Bausatz von WOGO (siehe #27) hatte ich heruntergeladen, da stand die Downloadzahl vorher wie nachher auf 1.

eTomNextBausatz.zip

Ich deute das Vergeben von Thanks als Zustimmung und habe obige Prüfungen implementiert.

 

sorry, bin gerad ein bissl eingeteilt. An sich find ich die Prüfungen gut.

Sobald ich ein bissl Luft hab schreib ich wieder mehr zu dem Thema.

Sobald ich ein bissl Luft hab schreib ich wieder mehr zu dem Thema.

 

mea culpa.

 

Da der Thread inzwischen ein bissl Gras angesetzt hat und wir nun doch direkt beim Community-EA das Template direkt erstellt haben, meine Frage:

 

Sollen wir hier mit der Templateversion des CommunityEAs neustarten und diesen zu einem "vollwertigen" EA-Template ausbauen?

 

Was mir vorschwebt ist ein Template, das möglichst einfach gehalten ist, aber trotzdem bereits alles beinhaltet inkl. Kommentarbereich mit "Hier Einstiegslogik einfügen" etc. Sodass jeder vom "Neuling" bis zum Experten schnell neue Ideen austesten kann.

 

Falls wir so ein Template hinkriegen, könnte man damit eine TomNext-EA-Kitchen aufmachen in der auf Basis dieses Templates jeder User Ideen vorstellen (oder von anderen Codern ausprogrammieren lassen) kann. Durch die gemeinsame Basis ist der "schnelle" Wechsel und damit Mitarbeit zwischen verschiedenen Ideen und EAs deutlich einfacher und unkomplizierter. Damit auch die Vermittlung von Coder zu Ideenproduzent etc. Aber das nur als Teaser was möglich wäre ;)

alles Kommentieren wäre extrem sinnvoll, finde ich und einem Ausbau zu einem "vollwertigen" EA-Template würde ich auch unterstützen

 

welche Komponenten dann als Sinnvoll erachtet bzw. gewünscht werden, soll hier doch jeder mal etwas Input beisteuern

Ok, für alle die jetzt nicht genau nachschauen wollen, hier die vorgeschlagene Version:

eTomNextKitchen.mq4

Es fehlen noch Kommentare, und man könnte noch Logging und die von Rainworm vorgeschlagenen Überprüfungen einbauen. bzw. weitere Verbesserungen...

 

Im Gegensatz zum anderen Grundgerüst würd ich inzwischen keine eigenen Libs für die verschiedenen Signale mehr vorschlagen, da es das ganze vor allem für neulinge extrem unübersichtlich macht. Ich denke wie gesagt das ein wichtiger Punkt für so ein "Grundgerüst" die Einfachheit ist. Komplexe, machtvolle Gerüste passt jeder Coder dann sowieso für seine eigenen Bedürfnisse an.

Sollen wir hier mit der Templateversion des CommunityEAs neustarten und diesen zu einem "vollwertigen" EA-Template ausbauen?

 

Da sich niemand dagegen ausspricht, mach ich einfach weiter ;)

 

Hab jetzt mal die Bedingungen von Rainworm miteingebaut. Und um mögliche Exitsignale erweitert.

Kommentare und Logging fehlen immer noch.

 

eTomNextKitchen.mq4

Hab jetzt mal die Bedingungen von Rainworm miteingebaut. Und um mögliche Exitsignale erweitert.

Einfach zu lieb, der Mythos (bin leider noch immer beruflich zu stark eingespannt...)

dann hier mal eine neue Version. funktionell is nix neu, aber mehr kommentare.

eTomNextKitchen.mq4

Ich würd gern die EA-Kitchen Idee nochmal aufgreifen. Sofern niemand von den beteiligten etwas dagegen hat, würd ich das Gerüst in ExpertAdvisors "vorstellen" gemeinsam mit der Idee der EA-Kitchen. Man könnte zB das LRD System als erstes in der Kitchen implementieren.

 

Meinungen, Vetos, Pros?

Meinungen, Vetos, Pros?

 

Ich nehm das mal als ein "keine Einwände" ;)

Ich nehm das mal als ein "keine Einwände" ;)

 

 

Ja bitte ... Du hast ja eine CC von "Ernten" und ich denke , dass ich von einem gewieften Coder wie Dir noch sehr viel dazu lernen kann .

Deine Tradebox hat mir schon sehr geholfen , da habe ich viel entdeckt, wass ich vorher garnicht wußte (s.a. RefreshRate() und der Thread von FX1)

 

Ich bin gespannt ....

 

KB

There we go: Tom Next EA-Kitchen