Positionsgröße mit negativem Wert - Seite 2

Neuer Kommentar
 
NoLimitations:

Ich habe auch gerade versucht, dies zu verwenden, ohne Erfolg. Möglicherweise ändert DTS einfach die Genauigkeit eines Wertes für das Aussehen und nicht den tatsächlichen Wert? Ich sehe keine anderen Optionen.

Ja, ich denke, die Zeichenkette macht den Wert im Double nur zu einer druckbaren Version davon, ändert ihn aber nicht. Ich bin mir nicht sicher, wie man das in MQL macht, aber ich weiß, dass man in Java eine Typumwandlung von einem Typ in einen anderen erzwingen kann (in diesem Fall von Double in Int).

Aus den Oracle-Dokumenten unter http://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html. Dies ist nur ein kleiner Teil des vorgestellten Codes.

// Casting conversion (5.4) of a float literal to
// type int. Without the cast operator, this would
// be a compile-time error, because this is a
// narrowing conversion (5.1.3):
int i = (int)12.5 f;
// String conversion (5.4) of i's int value:
System.out.println("(int)12.5f==" + i);

In Ihrem Fall würden Sie ihn etwa so formulieren 

int intConvertedDouble = (int) valueYouGotItFrom;

Natürlich müssten Sie die Namen anpassen, damit sie besser zu Ihrem Code passen.

http://www.studytonight.com/java/type-casting-in-java deckt es auch dort ab. Da Java und MQL beide auf C++ basieren sollen, könnte Ihnen das helfen.

 

@OP sowie das Lesen aller zuvor geposteten MQL4-Links siehe Arbeiten mit Doubles und PrintFormat

@JD4 Ich sehe nicht, wie das Posten von Java-Code und der Verweis auf Java-Spezifikationen dem OP hilft. Auch Java und C++ sind ähnlich, aber ich stimme nicht zu, dass es auf C++ basiert.

Obwohl Sie versuchen, hilfreich zu sein, denke ich, dass viele Ihrer Antworten, wenn Sie sich selbst nicht sicher sind, nur dazu führen, dass die Hilfesuchenden verwirrt werden.

 
ydrol:

@OP sowie das Lesen aller zuvor geposteten MQL4-Links siehe Arbeiten mit Doubles und PrintFormat

@JD4 Ich sehe nicht, wie das Posten von Java-Code und der Verweis auf Java-Spezifikationen dem OP hilft. Auch Java und C++ sind ähnlich, aber ich stimme nicht zu, dass es auf C++ basiert.

Obwohl Sie versuchen, hilfreich zu sein, denke ich, dass viele Ihrer Antworten, wenn Sie sich selbst nicht sicher sind, nur dazu führen, dass die Hilfesuchenden verwirrt werden.

In Bezug auf Ihre C++ Gedanken, werfen Sie einen Blick auf https://www.mql5.com/en/docs/basis. Dort steht es genau so, und da sie MQL4 modifiziert haben, um mehr wie MQL5(https://docs.mql4.com/mql4changes) zu sein, gilt es auch hier. Was meine Wissensbasis angeht, habe ich nie behauptet, ein Experte zu sein, und ich lasse die Leute wissen, wenn ich etwas poste, dass ich mir nicht sicher bin, zumindest versuche ich es, auch wenn ich es manchmal nicht weiß.Wenn ich einen Chevy fahre und Probleme damit habe, werde ich nicht dasitzen und den Rat von jemandem ablehnen, der nur an Fords arbeitet, wenn es ein hilfreicher Rat ist, auch wenn er vielleicht nicht ganz richtig ist. Ich werde auch nicht dasitzen und sagen, dass ich nicht glaube, dass du helfen kannst, wenn sie es tun, um hilfreich zu sein.
 

Ich glaube, Sie haben meinen Beitrag falsch verstanden. Mql4 OO basiert sicherlich auf C++, das ist wohl unbestritten. Ich habe mich auf Ihre Behauptung bezogen:

JD4: Since Java and MQL are both supposed to be based on C++, this might help you out.

gefolgt von vielen Java-Referenzen. Ich sagte -

ydrol: Auch Java und C++ sind ähnlich, aber ich stimme nicht zu, dass es auf C++ basiert.

Ich habe mich speziell auf Ihre Java-Referenzen bezogen. Java basiert meiner Meinung nach nicht auf C++.

Auf jeden Fall wurde das Thema der Darstellung von Dezimalstellen in Fließkommazahlen bereits mehrfach in den von WHRoeder erwähnten Threads behandelt.

Es sieht so aus, als wolle OP auf zwei Dezimalstellen runden, aber ohne eine Ausgabe oder spezifische Beispiele zu posten, nehme ich an, dass der Grad des Rundungsfehlers, den sie sehen, ignoriert werden kann.

 
JD4: Nicht laut der Doku-Seite dazu. https://docs.mql4.com/math/mathround
NoLimitations: JD4 hat recht, die Doku-Seite sagt, dass auf die nächste ganze Zahl gerundet wird.

Beides falsch. Es wird auf die nächste ganze Zahl gerundet. Irrelevant. Es gibt einen Double zurück . 1 = 1.0 = 1.00 = 1.00000 = 1.000000000000000000000000000000000000000000 UNENDLICH VIELE ZIFFERN

Lernen Sie über Gleitkomma. Der == Operand. - MQL4-Forum



 

Ich schätze, WH muss zurückgehen und noch einmal lesen, ich sagte, was die Seite sagte, dass die Funktion tat, nicht was sie tatsächlich tut. Und Computerprogrammierung ist einer der wenigen Orte, wo (int) 1 != (double) 1.00000000 (ad infinitum) in Bezug auf Datentypen.


@ ydrol, ich habe mit Ihrer Aussage zu MQL/Java/C++ nicht ganz verstanden, worauf Sie hinauswollen. Hier finden Sie einige Informationen über den Ursprung von Java als Programmiersprache.

https://en.wikipedia.org/wiki/Java_(programmier_sprache)

http://www.freejavaguide.com/history.html

Da beide fast das Gleiche in Bezug auf C++ sagen, werde ich aus Wiki posten: "The language derives much of its syntax from C and C++, but it has less low-level facilities than either of them."

 

Aus dem gleichen Zeitalter: "Die Syntax einer Sprache definiert ihre Oberflächenform.". (geschweifte Klammern usw.). Was in diesem Thread diskutiert wird, hat nichts mit der Syntax zu tun. Meiner Meinung nach ist die Aussage "Java basiert auf C++" in der gleichen Weise wie MQL, eine viel stärkere Aussage , der ich nicht zustimme.

Da es sich aber um eine qualitative Aussage handelt, können wir beide gleichzeitig Recht und Unrecht haben. Ich sehe immer noch nicht, wie die Java-Spezifikationen dem OP helfen, wenn es bereits einen spezifischen Link zu diesem Thema gibt und es sich nicht um eine syntaxbezogene Frage handelt.

Beide Artikel, die Sie erwähnen, betonen, dass Java Anleihen bei der Syntax macht - aber wenig anderes. Dies ist kein syntaxbezogenes Problem.

Es hängt jedoch mit derIEEE 754 Fließkommadarstellungzusammen, die von MQL verwendet wird und die auch von den anderen Sprachen genutzt wird. (und viele andere, die keine C-ähnliche Syntax haben - z. B. Pascal oder sogar Anwendungen wie Excel), und das liegt wirklich daran, dass es sich um einen Standard handelt, der von den meisten CPUs/FPUs unterstützt wird, und nicht an den syntaktischen Ähnlichkeiten der Sprachen. Das Problem ist, dass die Fließkommadarstellung von Dezimalbrüchen kleine Fehler aufweist. Der Auftraggeber möchte auf zwei Dezimalstellen runden. Das IEEE-754-Format kann weder ein Zehntel (0,1) noch ein Hundertstel (0,01) genau speichern. Im IEEE-754-Binärformat sind dies wiederkehrende binäre Brüche (so wie 1/3 ein wiederkehrender Dezimalbruch 0,33333 ist...) - Der Unterschied zwischen der beabsichtigten Zahl und der tatsächlichen Zahl ist recht klein (z. B. 0,00000000000001), aber groß genug, damit

1/10 != 0.1 // wahrscheinlich

Und int(0.1 * 10) könnte falsch gerundet sein.

Aber da OP nicht genau gepostet hat, was er sieht, wurde der beste Rat schon im 3. Beitrag dieses Themas gegeben: Lesen Sie die MQL-Threads. Ich sehe keinen Sinn darin, auch noch vorzuschlagen, dass sie die Java-Spezifikationen lesen sollen, nachdem die MQL-Threads gegeben wurden und sie wahrscheinlich keine Vertrautheit mit Java haben.

Zusammenfassung des Threads:

  • OP: Die Zahlen verhalten sich komisch
  • WHRoeader: Hier sind mehrere Links mit verschiedenen Erklärungen, warum sich Fließkommazahlen seltsam verhalten < Die Antwort ist hier irgendwo drin ...
  • OP: Ich habe sie verstanden, die Zahlen verhalten sich trotzdem komisch.
  • JD4: MQL4 und Java basieren auf C++, hier sind ein paar obskure Java-Links zum Thema Typecasting und Promotion, die selbst Java-Entwicklern schwerfallen würden.
  • ydrol: Wie genau hilft das dem OP? Ich stimme nicht zu, dass Java auf C++ basiert Die Antworten wurden vor einer Weile gepostet...
  • usw. usw.

 
Ich habe die Java-Art der Typumwandlung aus zwei Gründen gepostet: Erstens, weil ich zugegebenermaßen mit Java vertrauter bin, und zweitens, weil ich den Code durchsucht habe, und vielleicht, weil ich müde war, als ich es tat, nicht gesehen habe, wie man es in den MQL-Dokumenten macht. Um also zu versuchen, hilfreich zu sein, habe ich eine mögliche Lösung vorgeschlagen, von der ich einigermaßen sicher war, dass sie funktionieren würde, basierend auf der Annahme, dass MQL und Java angesichts ihrer gemeinsamen Vergleiche mit einer gemeinsamen Sprache, C++, nahe genug beieinander liegen.
 
JD4: Ich schätze, WH muss zurückgehen und noch einmal lesen, ich habe gesagt, was die Seite sagt, dass die Funktion tut, nicht was sie tatsächlich tut.
  1. Vielleicht sollten Sie zurückgehen und die Frage noch einmal lesen.
    NoLimitations: Warum sollte ich immer noch Antworten mit mehreren Dezimalstellen erhalten, wenn ich MathRound() verwende?
    Was auf der Seite steht, ist das, was sie tut. Sie rundet. Das hat nichts mit der Frage nach mehreren Dezimalstellen zu tun.
  2. Mehrere Nachkommastellen sind das, was passiert, wenn man ein Double ausgibt, ohne die erforderliche Anzahl anzugeben.
 
WHRoeder:
JD4: Ich schätze, WH muss zurückgehen und noch einmal lesen, ich habe gesagt, was die Seite sagt, dass die Funktion tut, nicht was sie tatsächlich tut.
  1. Vielleicht sollten Sie zurückgehen und die Frage noch einmal lesen.
    NoLimitations: Warum sollte ich immer noch Antworten mit mehreren Dezimalstellen erhalten, wenn ich MathRound() verwende?
    Was auf der Seite steht, ist auch das, was sie tut. Sie rundet. Das hat nichts mit der Frage nach mehreren Dezimalstellen zu tun.
  2. Mehrere Nachkommastellen sind das, was passiert, wenn man ein Double ausgibt, ohne die gewünschte Anzahl anzugeben.

Das obige war eine spezifische Antwort auf Ihren spezifischen Beitrag"MathRound gibt einen Double zurück; unendliche Anzahl von Dezimalstellen."

Noch einmal, laut der Dokumentationsseite.

"Rückgabewert

Wert gerundet auf die nächste ganze Zahl."

Nun eine konkrete Antwort auf diesen Teil Ihres Beitrags.

"Was auf der Seite steht, wird auch gemacht. Sie rundet. Das hat nichts mit der Frage nach mehreren Dezimalstellen zu tun."

Lesen Sie noch einmal das Zitat, dort steht "Wert gerundet auf die nächste ganze Zahl". Eine ganze Zahl ist per Definition eine ganze Zahl, also ohne Nachkommastellen. Und noch einmal, wenn das nicht das ist, was sie tatsächlich tut, dann ist der Code oder die Beschreibung fehlerhaft, und das eine oder das andere oder beides muss von MQ korrigiert werden, oder es muss ein Warnhinweis erscheinen, der besagt, dass diese Funktionen nicht wie angekündigt funktionieren.

Wenn sie tatsächlich den Typ zurückgibt, der ihr vorgegeben wird, aber mit dem mathematischen Äquivalent des nächsten ganzzahligen Wertes (z. B. gibt sie 1,00000 von 1,23456 zurück, und 1 == 1,00000), aber sie gibt keinen tatsächlichen ganzzahligen Typ zurück, dann muss auf der Referenzseite etwas angegeben werden wie "ändert den zugrunde liegenden Datentyp nicht" oder etwas anderes, das klar angegeben ist. Ich denke, das war eine flache Übersetzung von der russischen Originalseite, und als solche ist es nicht so klar auf Englisch, wie es sein sollte.

1234
Neuer Kommentar