Frage an die MQL4-Meister. Nochmals zu Double Compare. - Seite 7
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Dieses Gespräch scheint sich endlos fortzusetzen. Bis ein neuer Benutzer die entsprechenden Erfahrungen und Kenntnisse gesammelt hat, hat er in der Regel Zeit, mehrmals auf die Normalisierung zu stoßen.
Vielleicht ist es in MT5 sinnvoll, die Genauigkeit von reellen Zahlen bei Vergleichsoperationen zwangsweise zu begrenzen, z.B. auf 8 Nachkommastellen (d.h. NormalizeDouble() zwangsweise mit digit=8 ausführen).
Wenn die Vergleichsoperation wiederholt verwendet wird (z. B. bei wiederkehrenden Berechnungen), kann der Fehler bei der Eingabe auf 8 Stellen gerundet werden und bei der Ausgabe 1 betragen.
Ich habe eine solche Erfahrung mit der Berechnung von SmoothedAvarege gemacht, indem ich sie vor einem Jahr in meiner Bewerbung berechnet habe. Danach versuche ich, solche Arbeitsmethoden zu wählen, die die Ziffernkapazität von Doppelgängern nicht beeinträchtigen.
Oder, wie gravity001 vorschlug, zu INTam wechseln (was, wie Sie wissen, sehr zeitaufwendig ist).
Vielleicht ist es in MT5 sinnvoll, die Genauigkeit von reellen Zahlen bei der Durchführung von Vergleichsoperationen zwangsweise auf z.B. 8 Dezimalstellen zu begrenzen (d.h. NormalizeDouble() zwangsweise mit digit=8 durchzuführen).
Aber nicht nur benutzerdefinierte Operationen verlangsamen das Terminal, sondern auch solche, die ihm verborgen bleiben. Ich halte es für besser, einfach die Funktion ComparePrice in die Sprache einzuführen. Übrigens halte ich wie Irtron Point/2 für ein natürliches Maß (vielleicht besser Point *0,5). Um nicht jedes Mal dividieren/multiplizieren zu müssen, kann diese Hälfte zu einer vordefinierten Variablen gemacht werden. Solange das nicht der Fall ist, können Sie eine solche Variable selbst eingeben und sie beim ersten Start einmal berechnen. Allerdings können Entwickler die Funktion des Doppelvergleichs mit vordefinierter Genauigkeit erstellen, d. h. mit Ziffern anstelle von Punkt/2.
Du hast es vermasselt... :)
Der Vergleich von Gleitkommazahlen erfolgt durch den Vergleich des Differenzmoduls mit einem kleinen Schwellenwert.
Rückgabe (fabs(d1-d2) < 1e-10) zum Beispiel.
Was bringt es, die Dinge durcheinander zu bringen... Die Funktion NormalizeDouble(...) ist nur für hübsche Berichte gedacht.
Aber Sie verstehen nicht, worum es geht, Sie müssen genauer lesen. Der Kern der Frage ist der Programmierstil im Allgemeinen und im speziellen Fall von MT4.
Du hast alles durcheinander gebracht... :)
Der Vergleich von Gleitkommazahlen erfolgt durch den Vergleich des Differenzmoduls mit einem kleinen Schwellenwert.
Rückgabe (fabs(d1-d2) < 1e-10) zum Beispiel.
Was bringt es, die Dinge durcheinander zu bringen... Die Funktion NormalizeDouble(...) ist nur für hübsche Berichte gedacht.
Aber Sie verstehen nicht, worum es geht, Sie müssen genauer lesen. Der Kern der Frage ist der Programmierstil im Allgemeinen und im speziellen Fall von MT4.
Sie sollten uns besser sagen, was der Sinn dieser Frage ist. Andernfalls Hinweise - ich nicht! verstehen :)
Wenn es um Geschwindigkeit geht, führen moderne Prozessoren Gleitkommaoperationen aus
fast so schnell wie die ganzzahligen. Was den STYLE betrifft, so regiert leider der Pragmatismus...
Wenn es ASHIPS gibt, über welche Art von Stil reden wir dann? Hauptsache, es funktioniert. ...
Ansonsten gibt es kein anderes Problem als den Vergleich zweier Zahlen :))))))))
So etwas hätte ich von Ihnen nicht erwartet. Das dürfen Sie auf keinen Fall tun!
Wenn die Vergleichsoperation wiederholt verwendet wird (z. B. bei wiederkehrenden Berechnungen), kann der Fehler bei der Eingabe auf 8 Stellen gerundet werden und bei der Ausgabe 1 betragen.
Ich habe eine solche Erfahrung mit der Berechnung von SmoothedAvarege gemacht, indem ich sie vor einem Jahr in meiner Bewerbung berechnet habe. Danach versuche ich, solche Arbeitsmethoden zu wählen, die die Ziffernkapazität von Doppelgängern nicht beeinträchtigen.
Oder, wie gravity001 vorschlug, zu INTam wechseln (was, wie Sie wissen, sehr zeitaufwendig ist).
Warten Sie einen Moment. Es gibt keinen Grund, voreilige Schlüsse zu ziehen.
Erstens. Ich schlage nicht vor, den tatsächlichen Wert der realen Variablen selbst zwangsweise zu runden. Ich schlage vor, die Rundung der verglichenen Werte (Kopien) von Variablen zu erzwingen, wenn das Ergebnis einer Vergleichsoperation berechnet wird (für den Standardfall). Und natürlich darf der tatsächliche Wert der Variablen nicht angetastet werden. In diesem Fall wären keine anderen berechneten Werte betroffen, da die ursprünglichen Werte der Variablen, die in Vergleichsoperationen verwendet werden, ihre Werte beibehalten und Fehler in zyklischen Berechnungen nicht kumulieren würden.
Zweitens. Ich habe gesagt, dass wir diesen Weg einschlagen können, um Fehler mit härteren Folgen zu vermeiden. Um jedoch auch anspruchsvollere Berechnungen durchführen zu können, ist es notwendig, die Möglichkeit zu erhalten, die FunktionNormalizeDouble() mit bestimmten Parametern zu verwenden.
Mein Vorschlag schränkt also die Möglichkeiten der Sprache nicht ein, sondern erweitert sie.
Berücksichtigt man jedoch, dass bei Vergleichsoperationen in der Regel Preiswerte verwendet werden (d.h. Ziffer = 4), wird dieser Fehler in den allermeisten Fällen einfach nicht auftreten. Der Einsatz der vorgeschlagenen Technologie wird also die Zahl der Fehler verringern, die zu unvorhersehbaren Folgen führen.
Ist dies nicht der Fall, können Sie eine solche Variable eingeben und sie einmalig beim ersten Start berechnen.
Das können Sie nicht.
Oder besser gesagt, man kann Programmstrings schreiben, aber niemand (auch nicht die Entwickler) garantiert, dass der Wert dieser Variablen während der gesamten Lebensdauer des EA strikt unverändert bleibt. Es geht nicht um die Genauigkeit des Programmcodes, sondern um die technologischen Eigenschaften von Berechnungen und technologischen Regeln für die Speicherung der Werte von Variablen. Wäre dies nicht der Fall, gäbe es dieses Problem gar nicht.
Beim derzeitigen Stand der Dinge kann der ursprüngliche Wert der Variablen 123,00000000000 als 122,99999999999999 erscheinen, sobald er in Berechnungen verwendet wird. Und das, obwohl sich der Wert der Variablen seit ihrer Erstellung nie geändert hat und sie vom Programm nur aufgerufen wurde, um an anderen Berechnungen teilzunehmen.
Das ist der eigentliche Grund für die ganze Aufregung. Aus diesem Grund haben wir die Notwendigkeit geschaffen, NormalizeDouble() so nah wie möglich an der eigentlichen Berechnung zu verwenden, vorzugsweise direkt in der Bedingung von if-, for- und while-Anweisungen.
Und wenn das nicht möglich ist, können Sie eine solche Variable selbst eingeben und sie einmalig beim ersten Start berechnen.
Das können Sie nicht.
Oder besser gesagt, man kann Programmstrings schreiben, aber niemand (auch nicht die Entwickler) garantiert, dass der Wert dieser Variablen während der gesamten Lebensdauer des EA strikt unverändert bleibt. Es geht nicht um die Genauigkeit des Programmcodes, sondern um die technologischen Eigenschaften von Berechnungen und technologischen Regeln für die Speicherung der Werte von Variablen. Wäre dies nicht der Fall, gäbe es dieses Problem gar nicht.
Beim derzeitigen Stand der Dinge kann der ursprüngliche Wert der Variablen 123,00000000000 als 122,99999999999999 erscheinen, sobald er in Berechnungen verwendet wird. Und das, obwohl sich der Wert der Variablen seit ihrer Erstellung nie geändert hat und sie vom Programm nur aufgerufen wurde, um an anderen Berechnungen teilzunehmen.
Das ist der eigentliche Grund für die ganze Aufregung. Deshalb musste ich NormalizeDouble() so nah wie möglich an der eigentlichen Berechnung verwenden, vorzugsweise direkt in der Bedingung der if-, for- und while-Anweisungen.
Donnerwetter, ich glaube, ich beginne zu verstehen, worum es bei diesem ganzen Durcheinander geht...
Alles in allem muss ich mir wohl nichts ausdenken. Das hängt von der jeweiligen Situation ab. Was ist das Ziel? Wenn sich zwei Zahlen in der Mantisse um 0,1 unterscheiden können, und wenn das KRITISCH ist, ist es eine Sache, wenn es nicht wichtig ist, ist es eine andere. Es kommt darauf an, was miteinander verglichen wird. Aber die FLEXIBILITÄT, die ein ECHTER Compiler ohne Schnickschnack bietet, ist eine ECHTE und notwendige Sache, IMHO.
:)
Menschenskind, ich glaube, ich beginne zu verstehen, was die ganze Aufregung soll...
Im Allgemeinen glaube ich nicht, dass es irgendetwas zu erfinden gibt. Denn das hängt von der jeweiligen Situation ab. Was ist das Ziel? Wenn sich zwei Zahlen in der Mantisse um 0,1 unterscheiden können, und wenn das KRITISCH ist, ist es eine Sache, wenn es nicht wichtig ist, ist es eine andere. Es kommt darauf an, was miteinander verglichen wird. Aber die FLEXIBILITÄT, die ein ECHTER Compiler ohne Schnickschnack bietet, ist eine ECHTE und notwendige Sache, IMHO.
:)
Ich kann die Frage nach dem "Erfinden" nicht beantworten. Offenbar hängt es davon ab, woran man denkt:)
Zum Beispiel ermöglichen Erfindungen wie Point/2 in einigen Fällen tatsächlich Berechnungen mit einer gewissen Genauigkeit. Es ist jedoch besser, die Empfehlung der Entwickler zu befolgen, nämlich ein für allemal (bis zu einer neuen Dokumentation) die Funktion NormalizeDouble() bei der Berechnung von Vergleichsoperationen zu verwenden.
Es spielt keine Rolle, ob Sie NormalizeDouble() verwenden. Und wenn Sie sie nicht nutzen, ist das Glückssache.