Mythos

gerade "passiert" zwischen liteforex und Alpari: Nicht verwirren lassen, LiteForex rechnet in anderer Zeitzone (+1), es sind also beide um 11:00 passiert. kurze Rechnung: Pos1 gekauft bei 1.45995, verkauft 36 Sekunden später bei 1.45938 -> Diff: -0,00057 Pos2 verkauft bei 1.46050, zurückgekauft nach 35 Sek bei 1.45890 -> Diff: +0,00160 Also Einstiegsgap: 5,5 Pips, Ausstiegsgap: 4,8 Pips In Summe also 10,3 Pips Gewinn in 36 Sekunden Ja ich weiß, Demo und Ausnahme etc... aber in der Demo is es gar nicht so die Ausnahme. Ok, so extrem schon, aber in letzter Zeit schließt er fast keine Pos mehr mit Minus (also jeweils das Orderpaar betrachtet) Mal sehen wie der Unterschied im realen ist.

Meinst du mit "vertretbaren DD" jetzt 0 oder gibts auch bei positivem DD (also nicht 100% Gewinn) keinen Profitfaktor?

Genau genommen hab ich den Code dort fast direkt aus dem EA hier genommen ;) Was genau meinst du mit "live Daten"? Resultate aus Livetests? bzgl. Code: stimmt, aber die Idee is recht einfach, es is halt großteil viel "technisches" Zeug was man reincoden muss. EDIT: Test der letzten 2 Wochen, mit parallel 2 Parametervarianten hat auf den Demokonten 24.2 Dollar/Lot gebracht

Gibts noch jemanden der sich für das Thema/Projekt interessiert? Vor allem bzgl. Realtests und so ....

iHighest liefert dir den Index vom höchsten Wert im Array in dem du suchst. Wenn er dir jetzt sagt das das höchste Hoch im H4 vor 3 Bars war, und du schaust dir das High von vor 3 Bars im M5 an, ist klar das komische Werte rauskommen ;) Probier mal double hh7 = iHigh(NULL,PERIOD_H4,iHighest(NULL,PERIOD_H4,MODE_HIGH,7,2)); damit holst du dir das Element aus dem High-Array im H4 Chart. HTH

Moment, wolltest du 2 EAs am gleichen Chart laufen lassen? Das geht nicht, in MT kannst du pro Chart nur einen EA am laufen haben, ziehst du einen zweiten EA drauf, so wird der erste automatisch entfernt. Eine kleine MT-Library die ich mal geschrieben habe um oft verwendete Blöcke nicht ständig tippen zu müssen. (zB. das Senden einer Order mit Fehlerbehandlung, Parameternormalisierung etc.) gibts hier im Downloadbereich:

Bin mir nicht sicher ob das nicht eigentlich ein Bug ist oder wirklich von den Entwicklern gewünschtes Verhalten. Also darauf verlassen das es nicht irgendwann anders is (nach Update oder so), würd ich mich nicht ;)

Veto! Gerade getestet: eGlobVarTest.mq4 auf beliebigen Chart ziehen. Bei jedem Tick wird die Variable inkrementiert. sowohl nach einem Parameterwechsel, als auch einem TF Wechsel bleibt der Wert erhalten und zählt weiter rauf. Sogar ein Symbolwechsel lässt die Werte unbeeindruckt. lediglich neu kompilieren, bzw. EA vom Chart löschen und neu raufziehen, sorgt für das "Vergessen" der WErte. Nur weil init() aufgerufen wird, heißt das nicht das die globalen Variablen neu initialisiert werden. Das müsste man händisch machen.

Das wird MT intern eher schwierig da AFAIK nur Sekunden gemessen werden. Wenn die Ticks also in schnelleren Abständen als im Sekundentakt kommen, musst du dir eine externe (über dll) Zeitmessung überlegen ;)

Willst du nur ein Array, das für jeden Bar einen Wert speichert, oder diese Werte auch im Chart anzeigen? Wenn du vom EA aus Linien in den Chart malen willst wirds umständlich und ist auch von der Idee her nicht so gedacht. Einzige was mir da einfällt wären viele Objekte einfügen die dir eben die Linie nachmalt. Variante 1: Variable im EA global verwenden. Also die Variable nicht innerhalb einer Funktion definieren sondern außerhalb. Diese Variable gibt es dann im gesamten EA (also kann jede Funktion darauf zugreifen und ändern) und ist damit auch zwischen verschiedenen Aufrufen von start() vorhanden. Bsp: int globales_int_=0; void myFunction() { globales_int_ = globales_int_ + 1; } int start() { myFunction(); Print(globales_int_); } Wenn du das so kompilierst und testest, bekommst eine Liste von aufsteigenden Zahlen ausgegeben (1,2,3,4,...) und zwar genau bei jedem Tick eine neue Zahl. Sprich der Wert der Variable globales_int_ bleibt zwischen den Ticks erhalten. Variante 2: static Eine statische Variable ist eine Variable innerhalb einer Funktion, deren Wert aber zwischen den Aufrufen der Funktion erhalten bleibt. Bsp: int start() { static int statisches_int=0; statisches_int= statisches_int +1 Print(statisches_int); } void myFunction() { statisches_int = statisches_int + 1; //führt zu Compiler-Error } Nur die start() Funktion betrachtend macht dieses Bsp genau das gleiche wie das obige, die Funktion myFunction() würde aber einen "'statisches_int' - variable not defined" Error beim compilieren erzeugen, da die Variable nur innerhalb von start() existiert. Das Ganze geht natürlich mit allen Datentypen (inkl. Arrays). Wenn man eine Variable nur innerhalb einer Funktion braucht, ist es natürlich "schöner" sie als static innerhalb der Funktion zu machen als brutal eine globale Variable zu nehmen. Noch eine Warnung: Der Wert von globalen (und ich glaube auch statischen) Variablen überlebt in MT auch das PArameterwechseln. Der EA wird zwar neu initialisiert, aber die Werte der globalen Variablen sind danach immer noch die gleichen wie vor dem Parameterwechsel... das kann zu langen Fehlersuchen führen ;) Noch ein Hinweis: die hier beschriebenen "globalen Variablen" sind was anderes wie die GlobalVariables in MT. GlobalVariables sind Variablen die EA übergreifenden Funktionieren, das tun die hier beschriebenen nit. HTH

Wenn ich die Infos von FinGeR richtig deute dürfte es in gewisser Weise in MT5 einfach möglich sein, aber es ist auch in MT4 relativ einfach machbar: Du musst den Code nur ein bissl erweitern: benenn deine bisherige start() Funktion um in mystart() und mach eine neue start(): int start() { //---- int stop_counter=0; while(!IsStopped( ) && IsExpertEnabled() && IsConnected()) { if(!IsTradeAllowed()) { stop_counter++; if(stop_counter > 60*(1000.0/interval)) // assume Market to be closed break; } else stop_counter= 0; RefreshRates(); mystart(); Sleep(interval); } //---- return(0); } Damit wird mystart() alle intervall/1000 Sekunden aufgerufen (+die Zeit die die Funktion braucht), jedesmal mit aktuellen Daten (deswegen RefreshRates() ). Damit du den EA auch noch anhalten kannst und nicht jedesmal crashen musst damit du was ändern kannst (zB Parameter ändern) ist das "!IsStopped && IsEnabled" eingebaut. Also zum ändern von Parametern: EAs disablen -> Parameter ändern -> wieder enablen Zu "IsTradeAllowed": Während du eine Order sendest, gibt diese Funktion false zurück, dein EA würde also nach jeder gesendeten Order abbrechen und erst beim nächsten Tick wieder in die Schleife einsteigen, deswegen der Buffer. Ist das Trading für 1 Minute durchgehend nicht erlaubt, wird angenommen das was nicht passt und er steigt aus (startet aber beim nächsten Tick wieder in die Schleife). Darf man fragen welche Strategie du ca. verfolgst das du so zeitkritisch bist? *G* HTH

Soda, bin mal zurück von der "einsamen" Insel. Ich hab in den 2 Wochen den RobinHood mal mit einer mindestEinstiegsdiff von 0.00015 auf EURUSD in der Multivariante mit Alpari, MasterForex und LiteForex laufen lassen. Lotsize 0.01 jeder Account darf maximal 0.05 Lots offen haben. Derzeit Gesamt Gewinn 5.93 wobei gerade wieder 5 Positionen offen mit 1 Dollar offenem Gewinn. Davon wurden in der letzen Woche 1.95 Dollar gemacht. Getätigt wurden ca 3200 Trades. Also ca 0.185 Gewinn pro Trade und Lot. Es bleibt also nicht viel übrig, vor allem nicht wenn man ein so geringes Einstiegsdiff verwendet.

Es gibt Situationen da ist es egal was man(n) sagt, es kommt falsch an ... @Krümel: Also ich finde du hast mit deinem Wissen und Erfahrung (nicht nur im IT-Bereich sonder auch ganz allgemein) wesentlich zur Qualität und Niveau von Tom-Next beigetragen und durch die viele von dir investierte Zeit dafür gesorgt das Tom-Next das ist was es heute ist. Lass dich bitte nicht durch ein oder zwei unglücklich formulierte Posts (vor allem weil ich mir sicher bin das siscop es ganz anders gemeint hat als du es verstanden hast) demotivieren. Wenn alle die dir für deine Arbeit dankbar sind, sich ständig äußern würden, würde Tom-Next zu 50% aus "Danke Krümel" Posts bestehen ;)

Ich seh schon, wir verstehen uns. (Es ist auf alle Fälle gut solche Tools vorzustellen und damit blauäugigen "Gier frisst Hirn"-Tradern die Nase in die Realität zu drücken ;) Wie man anhand der Reaktion sieht, wird es ja nicht neutral oder positiv gesehen (egal wie es wirklich ist). Ich bin nicht viel im MQL Forum unterwegs, aber bis jetzt hatte ich eher den Eindruck das es dort mehr um die programmiertechnischen Fragen und Anwendungen des MT geht, und nicht um die Frage was die Broker tun. Und nur aufgrund des einen Post's in forexfactory ist jetzt schwer zu sagen warum der Post auf MQL gelöscht wurde. Wenn man sich die Grundstimmung dort anschaut kann es auch leicht sein das der Post derart formuliert war das MQL diese Art der Diskussion nicht auf ihrer Seite wollten. (Siehe die Posts von antiegonkress, da waren die Mods hier auch kurz davor sie zu löschen ohne das irgendwelche Vertuschungsgedanken dahinter standen) Zusätzlich kann es auch sein das MQL das Forum wirklich als reines Programmiersupportforum sehen will und damit solche Diskussionen als Offtopic löscht... Wie gesagt, ich hab keinen Ahnung warum es auf mql4 verbannt wurde (und selbst das es verbannt wurde haben wir nur die Aussage eines aufgebrachten Traders), aber es kann viele Gründe haben, die nix mit Vertuschung zu tun haben.

Das so etwas möglich ist, sind aber genau die Rahmenbedingungen in diesem Geschäft. Ich sag ja nicht das die Rahmenbedinungen gut sind, aber sie sind nunmal Fakt und wenn man sie nicht gut findet sollte man nicht mitspielen. Zu den ECN-Brokern: Dort hast du dann halt den realen Markt, und wenn der sich schnell bewegt gibt es vermutlich vielmehr Requotes als beim OTC.

Klassischer Fall von "Das wichtigste übersieht/vergisst man als erstes"

@siscop: Weißt du über dieses Tool mehr als das was auf dem Bild steht? Ich sag nicht das die angeführten "Features" alle positive Seiten haben, aber ich erlaube mir aufgrund von 7 Features eines Plugins, die man teils sehr negativ interpretieren kann, kein Urteil über die möglichen Anwender von diesem Plugin. Vor allem weil ich keine Ahnung habe wie das Leben für einen OTC-Broker ist, mit welchen Problemen der im Alltag zu kämpfen hat etc. Ich weiß, die Sündenbockphilosophie ist sehr praktikabel, vor allem wenn man wenig über den Sündenbock weiß außer das er der Feind ist. Aber wenn man bei einem OTC-Broker handelt, handelt man direkt gegen den Broker. Selbst wenn er sich im Markt gegenhedget herrschen auf der Kundenseite ganz andere Bedingungen als auf der Marktseite (Als Trader beim OTC-Broker erwartet man sich sofortige Ausführung wenn der Kurs den Limit erreicht, fixe maximale Slippage etc. das hast du im realen Markt alles nicht). Man kann es dem Broker also nicht verübeln wenn er versucht positiv auszusteigen. Wie gesagt: nicht falsch verstehen, es gibt sicher einige schwarze Schafe, aber ohne die andere Seite zu kennen alle Broker zu verurteilen passt irgendwie nicht in die Tom-Next Philosophie... Ich hab das Gefühl viele Leute gehen viel zu blauäugig in das Trading, sehen nur die geringen Fixkosten und Gebühren und den riesigen Gewinn der auf sie wartet. Das dieses Geld irgendwer anderes verlieren muss, und dieser Andere sich vermutlich dagegen wehren wird das Geld zu verlieren denken nur Wenige. Aber wenn er sich dann plötzlich wehrt ist er ganz ganz doll böse und hinterhältig etc. Beispiel Arbitragesystem: Nehmen wir an es funktioniert und bringt einen kleinen aber feinen konstanten Profit. Jeder Trader dem man es zeigt würd es vermutlich sofort einsetzen, aber wenn der Broker dann dem Trader Requotes liefert etc. dann ist es natürlich der böse Broker. Trading ist nunmal ein Kampf mit allen Mitteln, und wenn man selber alle Mittel einsetzt (oder einsetzen würde wenn man könnte) muss man es eben akzeptieren das es der andere möglicherweise auch macht. Nochmal: ich sag nicht das Broker die Tools nicht einsetzen, oder das diese Tools nicht dafür da sind es dem Trader zu erschweren Gewinne zu machen. Ich bin nur dagegen die Broker allgemein als hinterhältige Betrüger anzuprangern die alles tun um dem Kunden das Geld aus der Tasche zu ziehen. Vor allem weil wir nur eine Seite der Medaille kennen...

Versteht mich nicht falsch, ich kann mir gut vorstellen das manche Broker dieses Tool so einsetzen. Aber passiert hier nicht gerade eine massive Vorverurteilung aller OTC-Broker? Ich meine was wissen wir wirklich von dem Tool? Hat es jemand von euch schon verwendet/getestet? Alles was wir (ich zumindest) kennen ist diese Liste und die negativste Interpretation davon. Blödes Bsp Skalpell: Richtig beschrieben klingt es wie das schlimmst Mordwerkzeug überhaupt und die bösen, hinterhältigen Chirurgen verwenden das jeden Tag und tun so als wollten sie nur uns helfen. *sarkasm* Also stell ich mal die Frage in den Raum: Ist es nicht denkbar das ein solches Tool auch für "normales" Arbeiten eines Brokers verwendet wird? Ich meine das es unterschiedliche Kundengruppen gibt die unterschiedliche Prioritäten kriegen kann ich mir gut erklären. Stell dir vor wieviele "Anfänger" es in der Programmierung gibt. Wenn da einer (ungewollt) ein Skript schreibt was 100 (ungültige) OrderSend in der Sekunde schickt, sollte der Broker doch eine Möglichkeit haben diesen User nach hinten zu reihen um den reibungslosen Ablauf für die anderen zu gewährleisten. Ich will jetzt nicht unbedingt die Broker verteidigen oder so, aber ich denke sich kurzmal zu überlegen wie man agieren/denken würde wenn man auf der anderen Seite steht, kann nicht schaden.

C kann ich schon, aber mit Multi-Thread Systemen etc. hab ich mich noch nie befasst. Freu mich wenn du mitmachst, da kann ich sicher viel lernen. Ich bin nur die nächsten 2 Wochen nicht im Lande, also nur keinen Stress ;) Näherst? das war das erste worüber ich mir Gedanken gemacht habe ;) Ich wollte es nur erstmal bestmöglich hinkriegen ohne einen solchen Programmiertechnischen Aufwand zu betreiben wie du ihn gerade beschrieben hast. Unter anderem auch um mal zu testen wie das ganze überhaupt aussieht, und was machbar sein könnte. Da ich wie gesagt die nächsten 2 Wochen weg bin, hier mal der derzeitige Stand des Multi-Broker Systems. Es ist recht "dynamisch" programmiert, wodurch manche "Features" zwar noch vorhanden sind, aber nicht mehr benötigt werden. Aber es war für mich mehr ein learning-by-doing ;) EDIT: Was ich noch sagen wollte: Bei der derzeitigen (Kommunikations-)Variante über Files kommt es zwar gelegentlich zu "Verbindungsfehlern", da aber die Zeiten für das Senden einer Order (die im wesentlichen bestimmen wie lang man warten muss bevor der Alarm losgeht) sowas von weit über der Abtastrate des Marktes sind, werden solche Fehler eigentlich immer rausgefiltert und Unsynchronizitäten treten nur auf wenn wirklich eine Order nicht abgesetzt werden konnte... und das Problem kriegt man auch mit einer aufwändigen Server-Client Struktur nicht weg :(

Stimmt, aber wenn man sie sowieso getrennt betrachtet, ist es noch sicherer, es mit eigenen EAs zu machen (also jedes Paar kriegt einen eigenen DAteinamen und Chart. Damit kann man dann jedes Paar auch leichter auskoppeln etc. Ich denk das ein zusammenziehen von "unabhängigen" Systemen in ein Programm (EA/Script) unnötiges Risiko produziert. Vor allem weil die einzelne Variante gut läuft. (Ich kenn mich: Je mehr Code und komplexität, desto höher die Fehleranfälligkeit und desto schwerer das finden des Fehlers ;) Ich wollt einfach das "große Miteinander" probieren ;)

man muss dazusagen das ich gerade versuche mit minimalem Aufwand (auch was Codezeilen angeht) das ganze zu machen ;) so ein Netz wäre sicher möglich, aber das wäre dann ja ziemlich das gleiche als würde ich für jede Kombination einen eigenen "simplen" laufen lassen. (Also mit unterschiedlichen Dateinamen etc.). Die große Vorteile von mehreren Brokern wäre aber doch so ein "kreisgeschäft" oder? Gap BidA > AskB => A verkauft, B kauft Gap BidB > AskC => B verkauft (schließt die Order), C kauft -> B ist flat Gap BidC > AskA => C verkauft (schließt), A kauft(schließt) -> alle sind flat und es wurde optimalerweise bei jeder Transaktion ein "Gewinn" gemacht. Würde man das nur auf die Einzelpaare hin betrachten, so würde nach der Aktion Jeder eine Long und eine Short Position haben, die formal nichts miteinander zu tun haben. Um das mit dem Netz zu machen müsste man dann vermutlich intern ein bissl mehr aufwand betreiben um die Positionen herumzuschieben. Und falls eine Order nicht ausgeführt werden kann etc. hat man wieder das Problem zuzuordnen mit wem das jetzt war. D.h. man müsste den Orders (am besten in der MagicNumber) mitgeben aus welchem Broker-Paar es kommt und dann jedesmal vergleichen ob alle Orders die man wollte auch da sind. bzw. muss man dann das "gesamte" Netz immer wieder abgleichen. Derzeit gibt jede Instanz den anderen nur ihre aktuelle Positionsgröße bekannt und falls es hier zu einer Unstimmigkeit kommt wird bei dem Broker mit der größen Position die Position entsprechend reduziert. (zugegeben, das könnte man ändern auf "der Broker der als letztes eine Aktion hatte")

Soda, es ist wiedermal Zeit für einen Bericht von der "Front" ;) Da dlls keine Performanceprobleme machen, hab ich mir gedacht "Wieso nicht mehrere Broker?". Dabei ergeben sich viele neue Probleme was die "Synchronisation" (nicht im EDV-technischen Sinn sondern von der Strategie her) betrifft. Also das "wer hat gerade wieviele Positionen offen" ist nicht das Problem, das Problem ist eher das "Wer sollte gerade wieviele Positionen offen haben?". Vor allem wieder das Problem: Was ist wenn einer nicht ausgeführt wird oder möglicherweise sogar den Einstieg verschläft... Und noch ein Problem kommt dazu: Das ganze ist mit 3 Brokern schon ein bissl komplex zum verfolgen. Und wenn dann 3-4 Orders im Kreis laufen bzw. das System sagt das irgendwo was nicht stimmt, wird einem fast schon schwindlig beim zuschauen und erst recht beim Versuch herauszufinden was los ist... Aber es ist mal lustig zum zuschauen. Zeittechnisch schauts auch gut aus, ein Durchlauf von einer Instanz braucht bei 3 aktiven Instanzen (inkl. ein bissl grafischem Output fürs Auge) etwas über 8 Millisekunden also weit weg von kritisch.

Wenn du mir sagen kannst wie man das sinnvoll in MQL reinbringt würds mich interessieren sowas mal auszuprobieren.

Warum das Skript so lang braucht is schnell erklärt. Wenn ich Sleep(10) aufrufe sollte es ca 0.010 Sekunden brauchen. Das kann man in MT nicht messen. Also muss man Sleep(10) sooft aufrufen, bis man ein sinnvoll messbares Ergebnis hat und dann durchdividieren. Bei 50 Sekunden Messzeit ist +- 1 Sekunde schon noch eine "starke" Abweichung deswegen sind die Schleifen so eingestellt das sie ca. 10 Minuten laufen. Also jede Variante wird ca. 10 Minuten lang ausgeführt und dann überprüft wie lang das gedauert hat. Deswegen die lange Laufzeit. Dein PC weiß scheinbar wie man die Uhr liest ;) Obwohl du auch einen Overhead mit Faktor 1.006 hast... (aber besser als meine 1.09 !) Aber Krümel hat ja schon schön aufgezeigt das das scheinbar normal ist :( muss man halt den Intervall Parameter anpassen. Habs mal ohne Sleep getestet, die aktuelle Version braucht 0.3 Millisekunden pro Durchlauf (mit dlls) also dlls sind in keiner Weise langsamer

Nochmal zum "Sleep" Problem: Ich habs jetzt mal mit einer solchen Schleife getestet: start=TimeLocal(); counter=0; while(counter < 5000) { counter++; Sleep(10); } end=TimeLocal(); (da MQL ja nur in Sekunden die Zeit messen kann muss man den Mittelwert von mehreren Durchläufen nehmen). Die Schleife selber dürft keine zusätzliche Zeit brauchen weil ohne das Sleep kann man auch 100000 Durchläufe zeitlich noch nicht messen. Ergebnis bei mir: (auf verschiedensten MT Instanzen) Sleep(1) und Sleep(10) brauchen 15.6 Millisekunden, danach braucht Sleep(X) X*1.09 Millisekunden... Falls jemand das bei sich testen will: ich hab ein kleines Script geschrieben. Es braucht keine Rechenleistung und tut im wesentlichen nix außer die obige Schleife für mehrere Werte testen und dann das Ergebnis ausgeben. sSleepTest.mq4 Einfach auf einen Chart ziehen und warten bis im Experten-Reiter das Ergebnis geprintet wird. (Bei mir dauerts ca 40 Minuten) Wäre interessant ob mein PC vergessen hat die man die Uhr liest oder ob das allgemein so ist.