Ich stelle mal mein simples System zur Diskussion, ich runde ganz einfach auf 4 Stellen:

 

double o1 = NormalizeDouble(Open [1],4) ;

double c1 = NormalizeDouble(Close [1],4) ;

double h1 = NormalizeDouble(High[1],4) ;

double l1 = NormalizeDouble(Low[1],4) ;

 

double o2 = NormalizeDouble(Open [2],4) ;

...

 

 

'NormalizeDouble - Rounds the floating point value to the given precision' steht bei metaquotes. Ich gehe davon aus, das ist echtes mathematisches Runden, oder?

 

Mein EA kommt damit allgemein ganz gut zurecht. Doch einige meiner Kunden, die mit meinem EA bei 5 Digit Brokern traden, sind nicht zufrieden. Das muss aber nicht an den 5 Digits liegen, sondern einfach nur an der Kursstellung des Brokers. Mein EA reagiert sensibel auf kleine Unterschiede wie: h1>h2 oder h1>=h2.

So wird also ohnehin bei dem einem Broker ein Trade eingegangen, beim anderen nicht ...

 

Übersehe ich irgendwelche Nachteile die durch das Runden zu erwarten sind?

Mein EA kommt damit allgemein ganz gut zurecht.

 

Stelle diesen EA doch mal kurz vor. Welche Logik?

 

Dein EA lautet sicher: EA "Turm des Meeres" ... (Torre del Mar)

@ forextrading24

 

Sollte die Stabilität eines EA nicht höher sein, als daß er von 1/10-Pips abhängt?

Jeder Preis in der Trade-Funktion (OrderSend, OrderModify o.ä)

sollte normaliziert werden, deswegen brokerunabhängig würde ich es wie folgt die Preise aufbereiten:

 

double o1 = NormalizeDouble(Open [1],Digits) ;

 

Und um herauszufinden, warum nicht jeder Trade ausgeführt wird -

würde ich jede Antwort vom Broker auf Fehler überpüfen und die mögliche Fehler

mit der Funktion GetLastError() ausfindig machen und dementsprechend handeln

@ Technix: Warum 1/10-Pips? 4 Digits heisst ganze Pips. Eben weil die 1/10-Pips nicht interessieren, runde ich ja wie beschrieben.

@ Ecart: Die Logik wurde hier schon einmal an anderer Stelle dargelegt, ich hatte eine mq4-Datei hochgeladen die ein Beispiel zeigt. Es geht um wiederkehrende Chartformationen. Der expert hat mehr als zwei Dutzend als Beschreibung, quasi als Schablone, im Code vorliegen. Dabei geht es eben jedesmal darum, dass alle Bedingungen erfüllt sind,. Wenn eine der Bedingungen z.B. lautet h1>h2, aber h1==h2, passt die Formation nicht, es soll keine Position eröffnet werden. Aber bei einem 5 Digit Broker ist mir ein > von nur 1/10-Pip zu wenig.

 

Da komme ich auf ein anderes Problem: Für den Metatrader Strategietester sind es (ohne zu runden) manchmal doch h1>h2, obwohl im Chart dargestellt wird h1==h2. Oft genug wunderte ich mich, warum ein Trade im Backtesting ausgeführt wurde, live aber nicht - und umgekehrt

Ich habe mir im Journal mal die (angebliche) Differenz ausgeben lassen: In den dargestellten 8 Digits ist zwar erstmal nichts zu sehen, aber mal steht als Differenz +0.00000000 und mal -0.00000000 ! D.h. der Strategietester (viell. auch das Terminal) dichtet da hinter den 8 Stellen noch irgendetwas dazu. Viell. kann mir das ja einer der hier anwesenden Experten erklären. Nun, das Problem hat sich durch das Runden (fast) gelöst.

Das "Problem" liegt im Vergleich von 2 Zahlen von Typ "double".

Dieser Vergleich ist nicht korrekt, da die Zahlen im Programmspeicher

in der binären Form und der Länge von 8 Byte abgelegt werden und eine Abweichung

von z.B 0.00000000000001 das ganze Ergebnis "verfälschen könnte" ,

daher wird auch ein Vergleich auf GLEICH nie einen richtigen Ergebnis bringen.

 

Richtig wäre in dem Fall Vergleich auf Differenz

 

int   Genauigkeit = 4; // z.B 4 Digits
bool ist_gleich     = false;
double Zahl1 = 1.40000;
double Zahl2 = 1.40001;

if(NormalizeDouble(Zahl1 - Zahl2, Genauigkeit) == 0)
{
 ist_gleich = true;
 Print(" die Zahlen sind gleich!");
}
else  Print(" die Zahlen sind ungleich!");

...

daher wird auch ein Vergleich auf GLEICH nie ein richtiges Ergebnis bringen.

 

Das ist eine augenöffnende Auskunft, Danke!

 

Dann wird aber doch auch der Vergleich > oder < manchmal Fehler ausgeben,

denn ein GLEICH in der Kursstellung kann u. U. auch als > oder < interpretiert werden, oder?

 

Na, dann habe ich ja einiges nachzuprogrammieren

 

Wobei ich denke, wenn ich z. B. statt h1>h2 einfach h1>h2 +0.1*Point schreibe, oder +0.00001 (bei auf 4 Digits reduziertem Zahlenwerk) das Thema erledigt ist.

...

daher wird auch ein Vergleich auf GLEICH nie einen richtigen Ergebnis bringen.

 

Ich komme nochmal darauf zurück, weil der Vergleich auf GLEICH unter bestmmten Bedingungen wohl doch ein richtiges Ergebnis bringt:

Wenn ich 2 Zahlen von Typ "double" in meinem EA vergleiche, die direkt, also ohne weiteren Rechenschritt von einem Wert generiert wurden, funktioniert das.

Ich gehe mit meiner simplen nicht IT Profi Logik einfach mal davon aus, dass 2 im Ursprung gleiche Werte auch im Programmspeicher in der binären Form die gleiche Abweichung an der xten Stelle hinter dem Komma haben, also tatsächlich gleich sind.

Oder gibt es andere Gründe warum der Vergleich in der Praxis doch funktioniert?

Salu2

Heiko

Der Vergleich von Gleitkomma-Werten in der meistens benutzten prozessornahen IEEE 754-Darstellung mit '==' ist in den meisten gängigen Programmiersprachen (ABAP, Algol, C, C++, C#, COBOL, FORTRAN, Java, Javascript, Modula, Pascal, PL/1 u. v. a. m. und eben auch MQL als C-Ableger) in jedem Fall ein schwerer Programmierfehler.

 

Gleitkomma-Vergleiche sind immer in der Art if ( abs(wert1 - wert2) < epsilon_schranke ) durchzuführen, was in MQL4 z. B. mit NormalizeDouble() funktioniert.

 

Intern sind IEEE 754-Gleitkommazahlen etwa 15 Dezimalstellen genau, nur die Anzeige wird über die globale MQL-Variable Digits beschränkt, um nicht überall unsinnige, unübersichtliche pseudo-genaue Zahlenwürmer ansehen zu müssen.

 

Je nach vorigen Berechnungen können die letzten Stellen sehr schnell degradieren, also völlig wertlos werden, wobei je nach benutzen Funktionen und deren intern implementierten Algorithmen die Abweichungen um viele Größenordnungen höher sein können als die im Prozessor darstellbare Scheingenauigkeit.

 

Besonders Subtraktionen, gefolgt von Divisionen (also sehr häüfige und sehr einfache Rechenarten) erhöhen relative Fehler nahezu beliebig. Beispiel: 1,0000000003 1,0000000002 und 1,0000000001 unterscheiden sich um wenige Milliardstel, sind praktisch also gleich. Die Differenzen (jeweils von der ersten Zahl subrahiert) 0,0000000000 0,0000000001 und 0,0000000002 sind absolut immer noch gering. Werden diese aber dividiert, ist der Fehler riesig bis unendlich.

 

Sind nun durch vorangegangene Berechnungen die letzten Dezimalstellen ohnehin ungenau, sind Berechnungs-Resultate aus Subtraktionen und Divisionen immer mit einer ebenfalls im Berechnungsgang mitzuführenden Fehler-Fortpflanzungsrechnung auf Sinnfältigkeit zu prüfen. Wird die Fehlerschranke überschritten (bei der Genauigkeit von 15 Dezimalstellen, die der Prozessor bietet sind 6 Stellen, also ein Millionstel ein guter Wert), muß die Berechnung abgebrochen werden und eine Sonderbehandlung durchgeführt werden.