NormalizeDouble nicht wirklich
 

Hin und wieder berechnet mein NormalizeDouble-Befehl falsch.

Beispiel:
y=NormalizeDouble(x,2);
- da kommt dann ein Wert wie 95.400000000000000001

Kennt dieses Problem noch jemand und weiß einen Rat dafür?

Mittels Print(DoubleToStr(y, 2)); wird dann nur ausgegeben:

95,4

traderdoc

Ich muss den Wert in eine String bringen und mehere davon dann zu einer Kette aneinanderreihen, bevor ich sie anzeigen lasse. Darum geht das, glaube ich, nicht.

Das ist kein Fehler sondern völlig normal. Der Umgang mit Fließkommazahlen in einer Programmiersprache hat mit Zahlen im "normalen" Leben nur wenig zu tun. Eine Fließkommazahl wird aus einer Mantisse und einem Exponenten dargestellt.
Siehe: https://de.wikipedia.org/wiki/Gleitkommazahl

Na ja, ich denke hier hätte MetaQuotes etwas sorgsamer proggen müssen, denn diese kleine Fehlerchen können gravierende Fehler nach sich ziehen.
Bis zu der Stelle, wo die Fließkommazahl letztendlich errechnet wird, gebe ich Dir recht. Aber wenn per NormalizeDouble die Fließkommazahl z.B. auf 2 oder mehreren Stellen reduziert werden soll, dann kann das Ergebnis nicht 95.400000000000000001 lauten. Regelmäßige Fehler treten ja auf, wenn Fließkommazahlen als Price in OrderSend() angegeben werden, ohne! vorher NormalizeDouble verwendet zu haben, auch wenn man denkt, laut Mathematik, dass z.B. aus einer Division eine Zahl resultiert die dem Price-Format der Funktion OrderSend () entspricht. Erst mit NormalizeDouble(Wert, Digits) würde die Fließkommazahl maximal die Kommastellen haben, die dem Wert von Digit entspricht. Und dann tritt auch nie ein OrderSend-Fehler auf.
Daher denke ich, dass diese krumme Zahl 95.400000000000000001 nach der Anwendung von y=NormalizeDouble(x,2); als 95,4 vorliegt, nur durch die Anzeigefunktionen Alert() oder Print() werden solche krummen Zahlen angezeigt. Abhilfe schaft hier wiederum die bereits erwähnte Funktion DoubleToStr(Wert, 2).

traderdoc

Unmittelbar nach NormalizeDouble sollte für die interne Verarbeitung der Wert schon passen aber sobald damit nur eine Sache gemacht wird treten diese "normalen" Ungenauigkeiten auf.

In der Doku steht ja auch "Please note that when output to Journal using the Print() function, a normalized number may contain a greater number of decimal places than you expect."

Insofern ist das mit dem Print tatsächlich ein unnötiger Effekt auch wenn der Wert intern eigentlich stimmen würde. Daher der Weg über DoubleToStr ist dann für die Darstellung prima.

C$D

Ja, das Entscheidende hatte ich doch gerade vorher geschrieben!

traderdoc

Danke für Eure interessante Diskussion.
Damit hab ichs verstanden:

DoubleToStr(x, 2) wir mein Leben bereichern! :)

Immer wieder schön zu sehen, wie man mit Kleinigkeiten Glückseeligkeit bereiten kann.

traderdoc