Hallo,

seit ein paar Monaten beschäftige ich mich mit dem Programmieren eines EA.

Dass die Resultate von Backtesting und Live-Trading sich unterscheiden war mir schon vorher bekannt. Doch dass selbst simple Bedingungen, welche im Programm eine Order auslösen sollten im Live-Trading 'übersehen' werden, konnte ich mir vorher nicht vorstellen. So sollte z. B. nach einem Gap eine Kauf- bzw. Verkaufsorder ausgelöst werden. Am 14.1. 2009 um 1h wurden bei EURUSD im 1H Chart alle im Programmcode gestellten Bedingungen für eine Kauforder erfüllt - aber nichts geschah. Im Backtesting dagegen wird der Trade ausgelöst.

Hier die Codezeile:

if ((Open[1]>High [2])&& (Close [1]>High [2])&& (Low [1]>= High [2]))	  
  {
  res=OrderSend(Symbol(),OP_BUY ...

 

Andererseits werden immer wieder Orders ausgelöst, obwohl keine der vorgegebenen Bedingungen erfüllt wurde.

Es scheint, als ob die O-H-L-C Kurse die das Programm im Live-Trading 'sieht', sich von den gleichzeitig im Chart dargestellten Kursen unterscheiden. Liegt dies am Broker oder ist die Programmiersprache MQL des Metatraders fehrerhaft ? Oder werden im Live-Trading als input slippage oder spread mit einbezogen? Kann mir einer einen Tip geben, gibt es Abhilfe?

 

Auch scheint die Funktion 'ObjectGetValueByShift', welche den weiteren Verlauf einer mit zwei Punkten vorgegebenen Trendlinie berechnet, recht ungenau. Trades werden manchmal selbst im Backtesting so ausgelöst, als ob der Metatrader etwas anderes 'sieht' als im Chart dargestellt.

Sind dies unter Codern bekannte Probleme?

Saludos

Heiko

Hallo forextrading24,

 

willkommen hier im Forum...

 

Die Coder hier im Forum werden sicher bald antworten...

 

Bin leider (noch) nur Anfänger...

Herzlich Willkommen forextrading24.

 

Ich kann bei programmiertechnischen Dingen leider auch nur bedingt helfen,

bin aber überzeugt, dass sich zu dem Thema jemand melden wird und Dir bei der Umsetzung Deines Projektes zumindest in dem Punkt weiterhelfen kann.

 

 

Beste Grüße

whipsaw

Hallo,

ich hatte schon einmal gefragt, ob der Metatrader fehlerhaft ist.

Hier nochmal ein Beispiel, diesmal macht der Metatrader den gleichen Fehler sowohl im Live-Trading als auch im Backtesting. Oder mache ich einen Denkfehler?

Ich möchte, dass eine Sell Order nur getriggert wird, wenn ich im kurzfristigen Abwärtstrend bin (analog dazu buy). Um den Trend zu bestimmen nehme ich die Differenz von 2 Moving Averages, hier die von 4 Stunden, ich handle im 1H Chart.

Ein MA hat einen shift von eins, sonst sind sie gleich:

 

ma4=iMA(NULL,0,4,0,MODE_SMA,PRICE_CLOSE,0);
ma4a=iMA(NULL,0,4,1,MODE_SMA,PRICE_CLOSE,0);

 

Im Chart kann man sehen, wie im Abwärtstrend der ma4 unter dem ma4a liegt. Im Expert formuliere ich für den Sell: ... && (ma4 < ma4a)

Doch mein Expert löst die Sell Order aus, obwohl ma4 eindeutig grösser als ma4a ist (zumindest im _Chart).

Liegt es viell. daran, dass zu viele Bedingungen, im o.g. Fall sind es insgesamt 10 in der Programmzeile, von der Metaquote Programmiersprache nicht mehr verarbeitet werden können?

Eine Antwort eines Programmers wäre nett.

Thanxx

Heiko

Hier die Codezeile:

if ((Open[1]>High [2])&& (Close [1]>High [2])&& (Low [1]>= High [2]))

{

res=OrderSend(Symbol(),OP_BUY ...

 

Sind dies unter Codern bekannte Probleme?

Also ich hatte das konkrete Problem noch nicht, aber das heißt nix ;)

Hast du schon mal probiert die abgefragten Werte auszugeben?

Dann siehst du direkt ob die Daten anders als im Chart sind, oder ob du einen Denkfehler hast ;)

 

ma4=iMA(NULL,0,4,0,MODE_SMA,PRICE_CLOSE,0);

ma4a=iMA(NULL,0,4,1,MODE_SMA,PRICE_CLOSE,0);

 

Im Chart kann man sehen, wie im Abwärtstrend der ma4 unter dem ma4a liegt. Im Expert formuliere ich für den Sell: ... && (ma4

Doch mein Expert löst die Sell Order aus, obwohl ma4 eindeutig grösser als ma4a ist (zumindest im _Chart).

 

Da ist jetzt schwer etwas sagen ohne mehr vom Code zu wissen.

Was ich aus dem bisherigen Code vermuten kann: du berechnest hier den MA vom aktuellen (in Aufbau befindlichen) Bar, wenn du das bei jedem Tick machst, könnte das unerwünschte Folgen haben da ja das "Close" dann bis zum high raufwandert und bis zum Low fällt... wenn du also bei jedem Tick die Abfrage durchführst könnte das ein Grund sein.

 

Ansonsten würd ich wieder versuchen die Werte bei jeder Abfrage auszugeben und händisch zu kontrollieren...

 

HTH

I used everytick model and used close. Here is what I think is happening. When close is used for the current bar for which close is not stable, therefore when it is printed out it does not print the final close value. This close value gets stable only at the end of the period. All values of previous bar do not have such issue becasue all previous values are stable. Same thing applies to all LOW[0], CLose[0], High[0] except OPEN[0]. OPEN[0] is the only value for the current bar is stable value. For Technical Analysis purpose fuction should use only the stable values after the end of the bar and print out the same and not the during the period otherwise these values can not be used for developting tecnhcal indicators.

http://forum.mql4.com/15920

 

Meine Vermutung. Dein aktueller Bar ändert ja seinen Close dauernd bis der neue Bar anfängt. Eventuell wird zwischendurch die Bedingung erfüllt.

 

 

 

Zur Not schreib Dir alle Werte mal raus (Datei oder Terminalfenster). An der Menge an ver-Und-eten Bedingungen liegt's wahrscheinlich nicht. Kann man aber auch testen durch Einbauen von zusätzlichen If-Anweisungen:

 

if (b1 && b2 && b3 && b4 && b5)
{

 if (b6 && b7 && b8 && b9 && b10)
{
	 OrderSend(...)
 }

}

Hast du schon mal probiert die abgefragten Werte auszugeben?

 

Was ich aus dem bisherigen Code vermuten kann: du berechnest hier den MA vom aktuellen (in Aufbau befindlichen) Bar, wenn du das bei jedem Tick machst, könnte das unerwünschte Folgen haben da ja das "Close" dann bis zum high raufwandert und bis zum Low fällt... wenn du also bei jedem Tick die Abfrage durchführst könnte das ein Grund sein.

 

Ansonsten würd ich wieder versuchen die Werte bei jeder Abfrage auszugeben und händisch zu kontrollieren...

 

HTH

Diesmal warst Du schneller .

Sochle Groben Probleme beim Backtesting vs Live... am Forex mit MT4 sind mir nicht bekannt.

Die Fehler befinden sich wohl in deinem Code...

Diesmal warst Du schneller .

 

Wie gesagt, ich klick nie so häufig auf "Neue Beiträge" wie wenn ich lernen sollte und es ist gerade Prüfungszeit

Hi,

erstmal seid erstmal bedankt für eure Antworten. Aber die allg. Vermutung, dass mein aktueller Bar durch ändert seines Close den Fehler bewirkt, sollte doch durch:

 

//---- go trading only for first tiks of new bar
if (Volume[0]>3) return;

 

ausgeschlossen sein.

Ich habe nicht >1 sondern >3 gewählt weil ich direkt nach Schliessen einer Position, welches auf >1 reagiert, noch evtl. eine neue (entgegengesetzte) Pos. eröffnen möchte. Ob >1 oder >3 sollte für meinen expert keinen Unterschied bei der Entscheidung zur Eröffnung einer Order machen. Die 1, 2 oder 3 Pips mehr oder weniger machen keinen Unterschied bei Triggern einer Order. Ich handle mit 1H Kerzen und beziehe mich nur auf array [1] und höher, sollte also nichts bewirken.

 

Wenn der Fehler sich in meinem Code befinden sollte, liegt der dann wohl an Metaquotes:

Ich benutze eigentlich den 'Moving Average.mq4', der in der Metatrader Installation mitgeliefert wird. Nur meine sell/buy/close conditions sind andere. Ich beschreibe Candle Konstellationen.

Ist der 'Moving Average.mq4' fehlerhaft?

Mein expert fluppt im Backtesting wunderbar, selbst für den Zeitraum nach der Fertigstellung des experts. Wenn ich jede volle Std. einen Backtest machen würde und dann per Hand nachtraden, wäre ich dick im +. Aber im Live-Trading werden ständig Trades ausgelöst, die überhaupt nicht im Programm stehen. Ganz selten wird sogar bei laufendem Trade nach 1 Std. eine weitere Pos. eröffnet, als wenn die Funktion 'Calculate open positions' nicht funktionieren würde.

 

Interessant ist auch, dass im Livetrading-Chart nur die auch sich nachher im Backtest bestätigenden Trades mit Nummer (mouseover) und farbigem Pfeil angezeigt werden. In der Zeile zur Ordereröffnung:

 

res=OrderSend(Symbol(),OP_SELL,LotsOptimized(),Bid,3,0,0,"",MAGICMA,0,Red);

 

steht in jedem Modul (Bedingung) das einen Trade auslösen kann eine andere Nummer anstelle von "" und eine andere Farbe.

 

Was passiert da? Ist die Hardware meines Laptop etwa überfordert? (Acer, 1,8 GHZ, 1GB RAM)

Oder treibt der Server des Brokers (Varengold) ein böses Spiel mit mir? Er sieht ja, dass ein expert agiert, viell. will er ihn austricksen?

Zum Glück ist's ja bisher nur 'n Demokonto ...

Salu2

Heiko

Bearbeitet 6. Februar 200917 Jr. von whipsaw
<code> tags ergänzt

Ist die Hardware meines Laptop etwa überfordert? (Acer, 1,8 GHZ, 1GB RAM)

NEIN

 

 

Wenn der Fehler sich in meinem Code befinden sollte, liegt der dann wohl an Metaquotes:

NEIN

 

 

zeige bitte deinen ganzen code.

Kann mich da meinungsmäßig @FinGer nur anschließen. Irgendwas an Deinem Code ist buggy. Aber ohne Code ne Codereview machen - !

 

An MT liegt's nicht, da wären schon Generationen anderer Coder vor dir drüber gestolpert, zumal sich das auch nicht nach Rocket Science anhört, was Du da machts.

 

Aber manche Konzepte in MT sind gelegentlich anders umgesetzt als man sich das denkt und man arbeitet dann unter falschen Prämissen.

Kann mich nur FinGeR anschließen, obwohl ich verstehe wenn du den Code nicht offen legen willst (vor allem wenn er so ein Goldesel ist wie du sagst ;)

 

Also ein anderer Versuch: Du meinst, das Trades ausgelöst werden, obwohl im Chart die Bedingung nicht erfüllt ist, richtig?

Geh mal her und schreib per Print-Befehl in der If-Bedingung (also am besten direkt vorm OrderSend) alle Werte die in der Bedingung überprüft werden. Das könnte mögliche Denkfehler beheben. Falls das nix hilft, auch vor den Bedingungen output setzen. Liefert zwar viel Output zum analysieren, aber dann weißt was passiert und wo das Problem liegt.

 

Nebenbei: Wenn ein EA in beliebigen Backtest super Ergebnisse liefert, aber in live "versagt" ist es meist ein Hinweis für Backtestfallen.

Ich habe meinen expert einmal abgespeckt und nur den notwendigen Code drin gelassen um das in meinem vorherigen Beitrag beschriebene Problem zu erkennen. Es ist auch der einzige mir bekannte Fall, in dem Backtest und Live-Trading in der Fehlerhaftigkeit übereinstimmen. Ich hatte zuerst angenommen, die Vielzahl an Bedingungsketten, die eine Order auslösen können, wäre viell. das Problem. Bei mir sind es fast 50 solcher Module, wie ich sie nenne. In dem bereitgestellten expert ist nur ein einziges Modul vorhanden und trotzdem ignoriert der expert den Teil: ma<ma2

Wenn ich den expert im Backtest laufen lasse, wird am 3.2.'09 um 20h ein Sell ausgelöst, obwohl ma<ma2 eindeutig NICHT stimmt.

 

Aber, jetzt wirds interessant: Nur mit dem Finex Pro Trader (Version 4.00, Build 220), der von Varengold kommt, wird der Trade mit den Varengold Kursen ausgelöst. Das habe ich gerade erst festgestellt. Bei ActiveTrades Metatrader (ebenso Version 4.00, Build 220) wird der Trade nicht ausgelöst, obwohl sich die Kurse zum relevanten Zeitpunkt nicht nennenswert unterscheiden. Nicht nennenswert deshalb, weil die 2 Pips Differenz hier und da keine der Bedingungen im expert berührt. Die Variable xx als durchschnittl. gewichtete Schwankungsbreite H-L beträgt am 3.2.'09 um 20h übrigens knapp 53 Pips (lt. meinem Indikator dafür), für den, der es nachprüfen will. Erst wenn xx>59 Pips würde es eng. Aber so werden die Bedingungen ..>xx/4 und ..>xx/2 eindeutig auch bei ActiveTrades erfüllt. Die ..xx/16 ist hier garnicht relevant.

 

Es würde mich interessieren, ob noch jd. der den expert im Backtest laufen lässt, den Trade bei anderen Brokern ausgelöst bekommt!

 

Werde den Vorschlag mal umsetzen, per Print Befehl zu überprüfen. Danke für den Tip! Es wäre ein eindeutiger Beleg, dass der Metatrader spinnt, wenn ein Trade ausgelöst wird, ohne dass eine Meldung kommt. Eindeutiger als das Fehlen der Nr. des Moduls, das den Trade ausgelöst hat (wie zuvor beschrieben).

[hide]

Mom2.mq4

[/hide]

Bearbeitet 9. Februar 200917 Jr. von whipsaw
<hide>

Ich guck mir das mal bei alpari uk an. H1 EURUSD war der Wert/TF Deiner Wahl, wo das Problem auftrat, stimmt's ?

Welches Modell verwendest Du beim Backtest ?

@ forextrading24 - wenn Du Deine Codes vor dem Zugriff Neugieriger verstecken willst, dann benutze den hack.

Wenn es etwas ganz Spezielles ist und Du nur die Spezialisten um einen Code-Review bittest, dann können wir den betreffenden Beitrag auch in eines der Entwicklerforen verschieben. Zugriff wäre dann temporär, Du hättest aber die Gewissheit, dass die Informationen in dem kleinen Kreis blieben.

Ich guck mir das mal bei alpari uk an. H1 EURUSD war der Wert/TF Deiner Wahl, wo das Problem auftrat, stimmt's ?

Welches Modell verwendest Du beim Backtest ?

 

Ja richtig, sorry, hab ich vergessen zu erwähnen: H1 EURUSD

 

Modell? Den Backtester der im Metatrader mitkommt ...?

 

Aber wie gesagt, auch im Live-Trading wurde der Trade ausgelöst, mit der Nr. des Moduls das im expert vorkommt.

@ forextrading24 - wenn Du Deine Codes vor dem Zugriff Neugieriger verstecken willst, dann benutze den <hide> hack.

Wenn es etwas ganz Spezielles ist und Du nur die Spezialisten um einen Code-Review bittest, dann können wir den betreffenden Beitrag auch in eines der Entwicklerforen verschieben. Zugriff wäre dann temporär, Du hättest aber die Gewissheit, dass die Informationen in dem kleinen Kreis blieben.

 

Den <hide> hack habe ich vorher noch nicht entdeckt - aber was bringt der, wer sieht den expert dann noch? Ist mir aber auch nicht so wichtig ...

 

Dass ihr die Entwicklerforen schützt, verstehe ich ja. Aber warum ist seit heute plötzlich die Suchfunktion für Mitglieder unter 10 Beiträgen begrenzt?? Ich betreibe selber mehrere (Spanien)Foren und meine Moderatoren und ich würden wahnsinnig werden, wenn jede (dumme) Frage neu gestellt wird, weil keine Suchfunktion hilft die Antwort schon vorher zu finden!

Modell? Den Backtester der im Metatrader mitkommt ...?

Ok, wenn Du nicht weißt, wovon ich rede, ist es Nummer 1 in der Liste (der Defaultwert).

 

Geht nur um die Art, wie im Backtest die Abfolge der Datenpunkte modelliert wird (ob jeder Tick benutzt wird oder nur bestimmte Eckwerte). Inwieweit sich die 3 Methoden unterscheiden in Bezug auf BT-Ergebnisse, habe ich noch nicht im Detail herausgearbeitet (ist momentan auch hochuninteressant für mich *gähn*), ich wollte nur sicherstellen, dass die Einstellungen von uns beiden möglichst ähnlich sind, um den "Fehler" auch bei mir aus seiner Deckung zu locken bzw. ihn replizieren zu können.

Den hack habe ich vorher noch nicht entdeckt - aber was bringt der, wer sieht den expert dann noch? Ist mir aber auch nicht so wichtig ...

 

Dass ihr die Entwicklerforen schützt, verstehe ich ja. Aber warum ist seit heute plötzlich die Suchfunktion für Mitglieder unter 10 Beiträgen begrenzt?? Ich betreibe selber mehrere (Spanien)Foren und meine Moderatoren und ich würden wahnsinnig werden, wenn jede (dumme) Frage neu gestellt wird, weil keine Suchfunktion hilft die Antwort schon vorher zu finden!

 

 

Hide versteckt den Content vor denen, die nichts im Beitrag geschrieben haben - Erklärung ergibt sich daraus.

 

RE: Suchfunktion - das ist nicht seit heute so, sondern schon seit dem Du Dich angemeldet hast. Und auch wenn es sich Dir als Webmaster nicht gleich erschließt, dass hat seinen Grund.

Es würde mich interessieren, ob noch jd. der den expert im Backtest laufen lässt, den Trade bei anderen Brokern ausgelöst bekommt!

Meinst Du den hier ?

Btw. Dein Code ist nicht grade debugfreundlich, an Deiner Stelle würde ich z.B. die Ergebnisse der Auswertung der verschiedenen Conditions in Variablen schreiben, z.B.

 

bool crossing = Open[1]

 

Dann kannst Du Dir das Ergebnis besser angucken a la:

Print(" Open[1]

 

Und Du sparst Zeit, wenn Du Conditions nachnutzt, kannst z.B. !crossing==TRUE verwenden, um das Gegenteil zu testen

(bei Open[1]>Close[1] geht das zwar nicht, da der Fall Open[1]==Close[1] nicht mit enthalten ist, aber es geht eher ums Prinzip).

 

Ansonsten wirst Du doch weich beim Debuggen.

 

 

Wenn Dich die ganzen Debug-Zusatztexte nerven, da man sie nur ab und an braucht: wie wäre es mit etwa Ähnlichem wie einem "Debug-Flag", z.B.

ganz zu Beginn ne

bool print_all = true;

 

und immer an der Stelle, wo was ausgegeben werden kann, wenn der verantwortliche Coder mal wieder im Viereck hüpft, schreibt man

if (print_all == true){

Print(" Open[1]

}

 

So kannst Du die Ausgabe von Debuginfos über die eine Variable print_all ein- und ausschalten.

 

Muss aber jeder selbst wissen, nach was er sein erstes Magengeschwür benennen will.

if (... && (ma

{

}

Und bist Du Dir GANZ sicher, dass Du Hour() TATSÄCHLICH verwenden möchtest ?

 

 

int Hour( )

Returns the hour (0,1,2,..23) of the last known server time by the moment of the program start (this value will not change within the time of the program execution).

Note: At the testing, the last known server time is modelled.

http://docs.mql4.com/dateandtime/Hour

 

 

 

Was mir noch auffällt (ich liste es nur mal auf, da ich nicht weiß, was Du eigentlich vorhast):

 

Meinst Du WIRKLICH "Low[1]>ms2-xx/16" oder nicht doch "Low[1]>(ms2-xx)/16" ?

Und bist Du Dir GANZ sicher, dass Du Hour() TATSÄCHLICH verwenden möchtest ?

 

In EAs ist Hour() kein Problem, da man meist den Wert beim start der Funktion haben will. oder?

In EAs ist Hour() kein Problem, da man meist den Wert beim start der Funktion haben will. oder?

Da ich nicht weiß, was die Intention bei dem Programm ist, zähle ich nur die einzelnen Punkte auf, die man nochmal überdenken kann, ob die Bedeutung der Funktion usw. richtig verstanden und umgesetzt wurde.

Wenn es als OK "abgehakt" werden kann, umso besser. Fehler umzingeln, einkreisen und dann draufhaun... Klappt meistens. Meistens findet man nach diesem Ausschlussverfahren den oder die Schuldigen.

Da ich nicht weiß, was die Intention bei dem Programm ist, zähle ich nur die einzelnen Punkte auf, die man nochmal überdenken kann, ob die Bedeutung der Funktion usw. richtig verstanden und umgesetzt wurde.

Wenn es als OK "abgehakt" werden kann, umso besser. Fehler umzingeln, einkreisen und dann draufhaun... Klappt meistens. Meistens findet man nach diesem Ausschlussverfahren den oder die Schuldigen.

 

*ich hab nichts gesagt*

 

Ich denk der Debugoutput wird hier viel helfen.