Mythos

Das ist nicht unbedingt nötig. Ich hatte es damals beim RobinHood so gelöst, das der EA in einer Endlosschleife läuft und alle x millisekunden arbeitet. damit sind auch Orders etc. zwischen den Ticks möglich. Aber rein die Orderausführung ist für echtes scalping zu lahm. (nicht zu erwähnen mit den möglichen Delays aus dem Backend) Wenn du das Ticket etc. in 150ms erzeugst und dann 3 sekunden warten musst bis der Server auf deine Order antwortet (und du eh nur ein requote kriegst), weißt wo das Bottleneck is ;)

Rein für das Zeitthema: Ich hatte damals für das RobinHood-Projekt ja mehrere MT4 mit einer ähnlichen Technik synchronisiert (also gemeinsames File über dessen Inhalt entschieden wird welcher MT welche Order eröffnet). Hier hat es sich gezeigt das die gesamte Verarbeitungszeit des Schreiben und Lesen der Files defakto nicht ins Gewicht fällt, sondern im Endeffekt die Orderausführung von MT ewig dauert. (Vor allem so unterschiedlich wodurch der eine EA dachte die andere Instanz hatte keinen Fill, obwohl die Order einfach noch nicht durch war etc.) Also soweit scalpen mit MT(-Brokern) überhaupt Sinn macht, ist eine solche File-Schnittstelle definitiv kein Hinderniss.

hmmm also bei mir sitzt ein Lüfter direkt auf der CPU... Vergleiche zwischen Handelssystemen und CPU-Lüftern verkneif ich mir besser

Also ich bin gern dabei. Terminlich hab ich bei beiden noch frei und mal vorgemerkt, bin also flexibel. Da ich mit Bahn unterwegs bin, freu ich mich dann auf jeden Fall wenn ich einen der Übernachtungsplätze krieg ;) Nicht ganz, das Dinner ist voll auf cxalgos "Mist" gewachsen ;) Mein Vorschlag war ja das ganze mit einem TN-Treffen zu verbinden, aber das TN-Treffen im Augustiner machen wir besser ein paar Monate später wenns draußen schön warm is. ohja

Stimmt für Biergarten is grad suboptimales Wetter (Linz hat mich mit dichtem Schneefall begrüßt), da warten wir besser wieder auf die wärmere Jahreszeit. Und da is zum Kegel von "Kind und Kegel" a nimmer weit oder wie? "Auf der Alm gibts ka Sünd, weil wenn der Bauer raufkommt is er müde" ;)

Ich will mein Buch wenn dann nur persönlich abholen. (Nicht aus Datenschutzgründen sondern weil das Angebot so verlockend klingt) Bin ich eigentlich der einzige der nach München kommen würde? Wir könnten es ja mit einem TN-Treffen davor verbinden (also nicht bei cxalgo aber München hat ja angeblich Biergärten ;)? PS: ja, bin wieder in der westlichen Zivilisation aufgeschlagen (hab mich selten so gefreut, aber dazu in einem anderen Thread).

Im vorurlaublichen Tatendrang hab ichs jetzt mal implementiert. neuer initStop: double calcInitStopDiff(int orderType) { double initStopDiff=0.0; int shiftATR = indicatorShift; //shift für ATR in initerner ChandelierExit Berechnung double atr= iATR(Symbol(),Period(),ChandelierExitATRPeriod,shiftATR); if (orderType == OP_BUY) { initStopDiff= Ask - (High[iHighest(Symbol(),Period(),MODE_HIGH,ChandelierExitRange,0)]-atr*ChandelierExitATRMultiplier); } if (orderType == OP_SELL) { initStopDiff= (Low[iLowest(Symbol(),Period(),MODE_LOW,ChandelierExitRange,0)]+atr*ChandelierExitATRMultiplier) - Bid; } //Print("calcInitStopDiff: return("+initStopDiff+")"); return(initStopDiff); } Die Werte (sollten) im Fall das Chandelier was liefert genau gleich sein. Bin weiterhin für Wortmeldungen und Meinung offen, aber es soll ja auch was weitergehen ;) Nach dem Urlaub bin ich auch wieder mit dabei in der Analyse, Parameterauswahl und Optimierung. Nö, wird vermutlich ein Internetfreier Urlaub. Hab eh genug Kulturprogramm und die Freundin will ja auch nit zu kurz kommen

Find ich gut, ich habs jetzt einfach mal dazugetan damits einheitliche Shifts gibt. Deine Änderung im Trailing ist auch drin und als Version 1.1 hochgeladen. @InitStop: gibts dazu keine weiteren Meinungen? Ich würde ja ganz frech Licens Meinung als "pro meine Variante" nehmen, aber das wär dreist ;) Da die Diskussionsbeteiligung sehr klein ist folgender Vorschlag: Wir bauen die schnell zu machende Lösung (InitStop immer auf HH-x*ATR) ein, damit wir mal weiter testen und verbessern können. Möglicherweise stellt sich dann ja noch raus das der Chandelier als Filter doch gut ist. @Wolf: wär das für dich in Ordnung? Ich sehe nur das Risiko das bei einer Diskussion über Alternativen derzeit nur wir 2 diskutieren und wir die anderen langweilen ... @cxalgo: stimmt, sieht gut aus. Eigentlich war gedacht ihn auf M15 laufen zu lassen, aber scheinbar is H1 auch nit schlecht ;) Mit den Parametern is es dann eher ein "Scalper" als Trendfolger. Aber auch spannend wie der gleiche EA mit anderen Parametern die "Taktik" ändern kann. @all: Nicht wundern, ich flieg morgen 2 wochen auf Urlaub, kann dann also erst danach wieder antworten/einbauen.

Nicht unbedingt. Klingt nach einem simplem wackelkontakt. möglicherweise auch auch staub beim RAM kontakt oder so. bei solchen "umsteck"-aktion würd ich auch gleich ein entstauben dazuempfehlen, wirkt teils auch Wunder. Freut mich das wieder läuft.

Natürlich. Aber wenn am System nix geändert wurde, kein unkorrektes runterfahren etc. ist ein Fehler beim System bereits ähnlich wahrscheinlich wie ein spinnendes Hardwareteil. Zumindest in meiner bisherigen Erfahrung.

Sorry, aber da muss ich widersprechen. Ich hatte schon ein paar mal Probs beim booten, und Windows war noch nie die Ursache. Angefangen von defekten Ramsteinen über langsam sterbende oder ganz tote Festplatten (war damals auch ein stop im hochfahren bei x prozent) bis zu haarrissen im Motherboard oder wackelkontakt im Netzteil war alles dabei. Vor allem wenn man nix am System geändert hat macht ein Sicherheitscheck der Hardware schon Sinn. Ausbauen muss ja nit sein, aber zumindest den RAM mal softwaretechnisch checken lassen...

Hi, dann werf ich auch mal meine laienhafte unkompetente Fachmeinung dazu ;) Also wenn RAM wirklich (komplett) kaputt wäre, würde er bereits früher w.o. geben. Das hatte ich schon, das endet in einer "Peep"-show direkt nach power on, da kommst gar nicht bis zum Windows. Wenn nur einzelne Teile des RAM defekt sind könnte es zu sowas kommen. Die Zufälligkeit des einfrierens (30% - 60%) könnte dafür sprechen, da der RAM vermutlich nicht jedesmal genau gleich verteilt wird. Die Hardware/Prozesse werden aber normal in der gleichen Reihenfolge gestartet/gecheckt, wodurch er sonst eigentlich immer an der gleichen Stelle einfrieren sollte. Defekte HD wär auch eine Variante, im Sinn von einzelne Bereiche defekt welche möglicherweise für SWAP verwendet werden. Leider kann man bei sowas fast nix ausschließen, theoretisch könnte es auch Hardware sein die Dank wackelkontakt teils erst später spinnt teils a bissl früher. Ich würds im "Geht/Geht Nicht"-Stil mal alles abstecken (auch vom Motherboard) was nicht gebraucht wird. Also bis auf VGA und Festplatte alles und schaun obs dann immer noch ist. Die "beste" Version wäre natürlich wenn nur das Windows seine Tage hat und dich nicht mehr mag. Dann behebts eine Reperatur über die CD bzw. neuinstallation. Aber unbedingt vorher Daten sichern ;) hth

For the record: wenn das wirklich ernst gemeint ist bin ich gern dabei!

Der Chandelier macht eigentlich eine Kombination davon. Also für Long - ATR*Faktor. Er macht es eben nur immer für eine Richtung, aber ich finde man könnte wie gesagt diese Logik einfach direkt so nehmen. @Wolf: vollständig schon, von fehlerfrei hat keiner was gesagt

Da die Diskussion um den Chandelier eigentlich bereits in den Bereich "tut der EA was wir uns gedacht haben" fällt, hab ich noch die verbleibenden 2 Funktionen implementiert: //BreakEven extern bool BreakEvenActive = true; extern int BreakEvenATRPeriod = 13; extern double BreakEvenATRFaktor = 1.5; //MM extern int MMPercent = 0; //first priority, defines the relative Risk per Order extern double MMRisk = 0; //second. only used if MMPercent is 0. Defines the absolute Risk per Order extern double MMLots = 0.1; //third. only used if the others are 0. Defines the fixed Lotsize per Order //----------------------------------------------------------------- //# %Equity - es wird immer der angegebene % der Equity pro Trade risikiert //# fixer Betrag als Risk (wenn %Equity==0) //# fixe Lotzahl (wenn a) und b) == 0) //returns the lotsize for this order double calcLots(double stopDiff) { double lots= 0; double lots_step= MarketInfo(Symbol(),MODE_LOTSTEP); double risk= 0; if(MMPercent == 0 && MMRisk == 0) { lots= MMLots; } else { if(MMPercent != 0) risk= AccountEquity()*MMPercent/100; else risk= MMRisk; double point_value= MarketInfo(Symbol(),MODE_TICKVALUE)/MarketInfo(Symbol(),MODE_TICKSIZE); lots= risk/(stopDiff*point_value); } lots= MathFloor(lots/lots_step)*lots_step; lots= MathMin(MarketInfo(Symbol(),MODE_MAXLOT),MathMax(MarketInfo(Symbol(),MODE_MINLOT),lots)); return(lots); } //------------------------------------------------------------- // Breakeven nach Anstieg um x*ATR bool isBreakEven(double openPrice,int orderType) { if(!BreakEvenActive) return(false); double atr= iATR(Symbol(),Period(),BreakEvenATRPeriod,0); if(orderType == OP_BUY) { if(Bid > openPrice+atr*BreakEvenATRFaktor) return(true); else return(false); } if(orderType == OP_SELL) { if(Ask < openPrice-atr*BreakEvenATRFaktor) return(true); else return(false); } return(false); } Version 1.0 ist im Downloadmodul. Damit wäre die erste vollständige Version des EAs implementiert. Ist ja schon einiges an Code und Logik zusammengekommen. Die erste "Verbesserung/Logikproblem" wurde ja auch schon in Form des Chandelier als Init-Stop aufgedeckt. Ich würde sagen das behandeln wir als erstes. Also: Meinungen dazu? PS: Spannender Effekt derzeit: wenn kein initSL vorhanden ist greift die Lotsberechnung auf die fixen Lots zurück. Sind diese deutlich kleiner als die durchschnittliche prozentuelle Lotsize wird aus einer positiven Performance eine deutlich negative. Die Trades wo der Chandelier noch auf der falschen Seite ist, sind also scheinbar sehr wichtig für die positive Entwicklung. mMn ein weiterer Grund warum wir ihn nicht als Filter einsetzen sollten, bzw. wenn als umgekehrten Filter: Nur einstieg wenn chandelier auf der "falschen" Seite. Als kleiner Teaser: Ergebnis einer ersten Optimierung auf 1 Jahr. die Parameter die sich hier ergeben haben sind äußerst spannend und geben sicher Diskussionsbedarf für die Logik, aber dazu mehr später.

naja, aus meiner Sicht implementiert der Chandelier eine Idee: "Aussteigen wenn der Kurs x*ATR unter das maximum fällt". Diese Idee liefert eine Berechnung für den Long und eine für den Short fall. Der Chandelier inkludiert halt noch einen "geratenen" Trend und gibt nur die entsprechende Berechnung aus. Da wir aber den Trend "selber raten" wäre es trotzdem in der Idee des Chandelier hier die entsprechende Berechnung für "unseren" Trend zu nehmen. Gibts noch andere Meinungen dazu?

das wär von Linz ja direkt ums eck ;)

und führe uns nicht in Versuchung ;) (wo überhaupt?)

Ja ich glaube da gab es auch missverständnisse. Fragen wir mal so: was macht der Chandelier? Er berechnet doch <HH der letzten x-Bars> - ATR*Faktor oder? Sobald das gebrochen wird dann wechsel auf short, aber immer die gleiche berechnung. was spricht also dagegen den InitStop genau auf dieses Level zu setzen? Also der Chandelier wo er wäre, wenn er er den Trend in diese Richtung sehen würde... Die Idee vom Chandelier ist ja auch was wir hier ja machen würden. Edit: als Filter würde ich ihn nicht nehmen, da er ja dem Trend-start hinterherhinkt. wir wollen aber mit dem HA den Start direkt erkennen und nutzen. Ich verwende den Parabolic normal auch ein wenig anders. Mit newStop= oldStop + (ExtremPoint-oldStop)*afFactor also die Idee des parabolic auf eigene Werte angewendet.

jup

Ich habs jetzt mal in ein eigenständiges Thema ausgelagert. Sofern die Beteiligung hoch ist, wird dieser Thread eine Sammlung der besten Backtest & Optimierungs threads bei TomNext. Vorschläge für neue Threads einfach posten, sie werden ggf. in den ersten Post eingefügt. Mit der nächsten Version der Boardsoftware bekommen wir vermutlich zusatzfeatures dazu, die solche Sammlungen womöglich überflüssig machen, deswegen bis dahin diese "Übergangslösung".

So, endlich die zusammengebaute Version. Ich hab das Kriterium beim Trailingstop im Fall Short noch leicht geändert: (orderType == OP_SELL && trailStop > 0.0 && (curStop == 0 || trailStop < curStop)) damit wird auch getrailed wenn es keinen Init-Stoploss gibt. Im Long fall ist das sowieso der Fall. Für das genaue durchschauen der Funktionen fehlt mir derzeit leider die Zeit, aber sieht sehr gut aus. Hier Version 0.6: eTomNextCommunity.mq4 Ich stell es hiermit auch in den Downloadbereich in der Kategorie "community-projekte", dann muss man für die aktuellste Version nicht mehr den Thread durchackern ;) EA im Download ab sofort stell ich das File dann nur noch ins Downloadmodul. EDIT ganz vergessen: was noch fehlt: double calcLots(double stopDiff) // Lotsizeberechnung nach abhängig von externem Parameter bool isBreakEven(double openPrice,int orderType) // check ob BreakEven-Trigger erreicht danach würde ich sagen wir schauen uns mal an (mit konkreten Chartbeispielen) was der EA tut und ob er überhaupt das tut was wir wollen.

Vielen Dank für das Update , werd die vollständige Version 0.6 so bald wie möglich reinstellen. Da haben wir uns vermutlich falsch verstanden. Aus meiner Sicht war es geplant das in der Berechnung des neuen Trailingstops, automatisch das "nur nach oben nachziehen" inkludiert ist. Deswegen auch der aktuelle Stop als Parameter. Ich würde also diese Abfrage noch in die Trailingfunktion packen. Die anderen Funktionen muss ich mir erst genau durchschauen.

ja sollte funktionieren. Er wertet zuerst die Expression innerhalb der (...) aus und gibt den Wert zurück. Eigentlich nur weil ichs so gewohnt bin und alle anderen Parameter im Moment auch in Kapitälchen ohne _ sind. Es geht nur um einheitliche Conventionen, damit man im Code sofort sieht ob das eine lokale Variable, globale Variable oder externer Parameter ist. Mir fällt grad auf, das die Filter-Parameter auch "_" drin haben. Wie machen wirs? Kapitälchen mit oder ohne "_"? @MA: Funkt so leider nicht. Der Parameter bei iMA ist kein String. MODE_EMA ist eine vordefinierte Konstante und eigentlich ein integer. "sicher" wäre es wenn man die MODE-Konstante per Parameter übergibt. extern int FilterMAMode = 1; // 0 - SMA, 1 - EMA, 2 - SMMA ... //------------------------------------------------------------------------------------------------+ // KB was here| // übergeordneter Trend erkannt durch Abstand von 2 MAs, dient als Filter für die Einstiege. | // returns one out of FLAT, LONG, SHORT | // | // verwendete Parameter: | // TF_MA = 240 , FS_MA_Schnell = 3 , FS_MA_Slow = 6 ;// 4 Std TF , MA 12Std und 1 Tag | // MinFilterGap = 0.0025 // Distanz zwischen den beiden MA | int calcFilterSignal() { // | double abstand; // | double ma_Schnell = iMA (Symbol() , TF_MA , FS_MA_Schnell , 0 , FilterMAMode ,PRICE_CLOSE ,0) ;// | double ma_Slow = iMA (Symbol() , TF_MA , FS_MA_Slow , 0 , FilterMAMode ,PRICE_CLOSE ,0) ;// | In dem Fall kann man dann ggf. später auch weitere Codes für andere MAs einfügen.