Fehler, Irrtümer, Fragen - Seite 1931
![MQL5 - Sprache von Handelsstrategien, eingebaut ins Kundenterminal MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Morgens ist es immer besser... :)
Im Helpdesk
MT4:
Für Objekte mit fester Größe: OBJ_BUTTON, OBJ_RECTANGLE_LABEL und OBJ_EDIT Eigenschaften OBJPROP_XDISTANCE und OBJPROP_YDISTANCE legen die Position des oberen linken Objektpunktes relativ zur Diagrammecke (OBJPROP_CORNER) fest, von der aus die X- und Y-Koordinaten in Pixel gezählt werden.
MT5:
Für Objekte mit fester Größe: OBJ_BUTTON, OBJ_RECTANGLE_LABEL, OBJ_EDIT und OBJ_CHART, legen die Eigenschaften OBJPROP_XDISTANCE und OBJPROP_YDISTANCE die Position des oberen linken Punktes des Objekts relativ zur Diagrammecke (OBJPROP_CORNER) fest, von der aus die X- und Y-Koordinaten in Pixel gemessen werden.
Das Problem ist, dass die alte Version von MT4, die ObjectSet verwendet , die Platzierung von Objekten relativ zu ihren Kanten (Ecken) erlaubt - für Objekte im linken Teil wird die Berechnung der Pixel vom ersten Symbol aus durchgeführt, für Objekte im rechten Teil - vom letzten Symbol aus, während die neue Version die Berechnung immer vom ersten Symbol aus durchführt, was die Positionierung von Etiketten mit Text schwierig macht, weil man nicht immer weiß, wie viele Textsymbole es geben wird. Ich fordere die Entwickler auf, eine Auswahl an Textausrichtungsmethoden hinzuzufügen!
Wenn jemand weiß, wie man sich in MT5 links und rechts ausrichten kann, bitte die entsprechende Funktion mitteilen!
Und ärgern Sie sich nicht, sondern lesen Sie die Hilfe aufmerksam:
Für die Objekte OBJ_LABEL, OBJ_BITMAP_LABEL und OBJ_RECTANGLE_LABEL können Sie den Kartenwinkel einstellen, relativ zu dem der Objektankerpunkt positioniert wird. Dieser Winkel wird über die Objekteigenschaft OBJPROP_CORNER festgelegt, die einen der vier Werte der Aufzählung ENUM_BASE_CORNER annehmen kann:
Kennung
Beschreibung
ECKE_LINKS_OBEN
Koordinaten des Ankerpunkts in Bezug auf die linke obere Ecke des Diagramms
ECKE_LINKS_UNTEN
Die Koordinaten der Ankerpunkte werden relativ zur linken unteren Ecke der Karte angegeben.
ECKE_RECHTS_UNTEN
Ankerpunktkoordinaten werden relativ zur unteren rechten Ecke des Diagramms festgelegt
ECKE_RECHTS_OBEN
Die Koordinaten des Ankerpunkts werden relativ zur oberen rechten Ecke des Diagramms festgelegt
Die Position des Ankerpunkts des Objekts wird durch die Eigenschaft OBJPROP_ANCHOR angegeben und kann einer der 9 Werte der Aufzählung ENUM_ANCHOR_POINT sein:
Kennung
Beschreibung
ANKER_LINKS_OBEN
Verankerungspunkt in der oberen linken Ecke
ANCHOR_LEFT
Verankerungspunkt links in der Mitte
ANKER_LINKS_UNTEN
Verankerungspunkt in der linken unteren Ecke
ANCHOR_LOWER
Verankerungspunkt unter der Mitte
ANKER_RECHTS_UNTEN
Verankerungspunkt in der rechten unteren Ecke
ANCHOR_RIGHT
Verankerungspunkt rechts in der Mitte
ANKER_RECHTS_OBEN
Verankerungspunkt in der oberen rechten Ecke
ANCHOR_UPPER
Verankerungspunkt in der oberen Mitte
ANCHOR_CENTER
Verankerungspunkt genau in der Mitte des Objekts
Soll ich den Listeneintrag, den Sie mit der Zahl 4 zu kennzeichnen versuchen, die es nicht gibt, nach oben verschieben? Es wird Null - und alles ist an seinem Platz.
Natürlich habe ich alles verschoben - vielleicht bin ich dumm...
Und ärgern Sie sich nicht, sondern lesen Sie die Hilfe aufmerksam:
Für die Objekte OBJ_LABEL, OBJ_BITMAP_LABEL und OBJ_RECTANGLE_LABEL können Sie den Kartenwinkel einstellen, relativ zu dem der Objektankerpunkt positioniert wird. Dieser Winkel wird über die Objekteigenschaft OBJPROP_CORNER festgelegt, die einen der vier Werte der Aufzählung ENUM_BASE_CORNER annehmen kann:
Kennung
Beschreibung
ECKE_LINKS_OBEN
Koordinaten des Ankerpunkts in Bezug auf die linke obere Ecke des Diagramms
ECKE_LINKS_UNTEN
Die Koordinaten der Ankerpunkte werden relativ zur linken unteren Ecke der Karte angegeben.
ECKE_RECHTS_UNTEN
Ankerpunktkoordinaten werden relativ zur unteren rechten Ecke des Diagramms festgelegt
ECKE_RECHTS_OBEN
Die Koordinaten des Ankerpunkts werden relativ zur oberen rechten Ecke des Diagramms festgelegt
Die Position des Ankerpunkts des Objekts wird durch die Eigenschaft OBJPROP_ANCHOR angegeben und kann einer der 9 Werte der Aufzählung ENUM_ANCHOR_POINT sein:
Kennung
Beschreibung
ANKER_LINKS_OBEN
Verankerungspunkt in der oberen linken Ecke
ANCHOR_LEFT
Verankerungspunkt links in der Mitte
ANKER_LINKS_UNTEN
Verankerungspunkt in der linken unteren Ecke
ANCHOR_LOWER
Verankerungspunkt unter der Mitte
ANKER_RECHTS_UNTEN
Verankerungspunkt in der rechten unteren Ecke
ANCHOR_RIGHT
Verankerungspunkt rechts in der Mitte
ANKER_RECHTS_OBEN
Verankerungspunkt in der oberen rechten Ecke
ANCHOR_UPPER
Verankerungspunkt in der oberen Mitte
ANCHOR_CENTER
Verankerungspunkt direkt in der Mitte des Objekts
Danke, ich werde versuchen, mir morgen etwas einfallen zu lassen...
Morgens ist es immer besser... :)
Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien
Wanzen, Wanzen, Fragen
fxsaber, 2017.07.18 09:51
Eine fast kindliche Frage: Warum ist das so?Aus irgendeinem Grund war ich sicher, dass DoubleToString nach der Normalisierung bedeutungslos ist. Aber nein, wie das Drehbuch zeigt. Warum ist dies der Fall?
Es scheint, dass die Konvertierung Double -> String nicht richtig funktioniert.
Dieses Beispiel ist ziemlich kompliziert zu verstehen, deshalb habe ich ein anderes gewählt.
Ich meine Folgendes.
Строковая в double переводится без проблем. Обратно - получаем другой результат.
D.h. ich habe die Zeichenkette "8.905" genommen, sie in double und sofort in string umgewandelt und so 8.904999999999999 erhalten. Aber die erste Zeile von OnStart zeigt, dass (double) "8.905" == 8.905. Das heißt, 8,905 sollte gedruckt werden.
Natürlich sollte die offensichtliche Null-Situation nicht funktionieren:
Nachdem ich das Problem ein wenig untersucht habe, bin ich zu folgender Situation gekommen
Erläutern Sie bitte, warum die Umwandlung double -> string immer noch als korrekt gilt. Das letzte Beispiel hat mich völlig aus den Socken gehauen.
Erläutern Sie bitte, warum die Konvertierung Double -> String immer noch als korrekt angesehen wird. Das letzte Beispiel ist wirklich umwerfend.
Kommentar zum letzten Beispiel
Reelle Zahlen können als identisch betrachtet werden, wenn sie die gleichen Umwandlungen durchlaufen haben. Selbst scheinbar identische Umrechnungen - num*0,5 und num/2,0 - führen zu unterschiedlichen Ergebnissen. Das Gleiche gilt für Spiegeloperationen. num*=num2, num/=num2. Die resultierende Zahl ist nicht gleich der ursprünglichen Zahl. Willkommen in der Welt der reellen Zahlen.
Während des Normalisierungsprozesses wurden in dieser Stichprobe 3 Operationen mit einer reellen Zahl durchgeführt - num*=1000, num+=0,5, num/=1000.
Sie können die Schritte im Debugger überprüfen
SD sagt, dass es in diesem Fall richtig ist.
Warum ist das verwirrend?
Die große Mehrheit der reellen Dezimalzahlen lässt sich nicht als binärer Bruch ohne Rest darstellen. Wenn man dann noch ein doppeltes Speicherformat hinzufügt, erhält man solch hässliches Zeug.
Eigentlich wäre der Dezimaltyp schön, er ist praktisch.
Kommentar zum letzten Beispiel
Reelle Zahlen können als identisch angesehen werden, wenn die gleichen Umrechnungen an ihnen vorgenommen werden. Selbst scheinbar identische Umrechnungen - num*0,5 und num/2,0 - führen zu unterschiedlichen Ergebnissen. Das Gleiche gilt für Spiegeloperationen. num*=num2, num/=num2. Die resultierende Zahl ist nicht gleich der ursprünglichen Zahl. Willkommen in der Welt der reellen Zahlen.
In diesem Beispiel wurden während der Normalisierung 3 Operationen - num*=1000, num+=0,5, num/=1000 - an einer reellen Zahl durchgeführt.
Sie können die Schritte im Debugger überprüfen
Sehr konstruktive Erklärung, danke!
Aber dieses Gegenbeispiel macht mich sprachlos.
Soll die Normalisierung so funktionieren?
Warum ist das verwirrend?
Nach der Erklärung von Slava ist es nicht verwirrend, aber dann gibt es ein Beispiel, das uns die Korrektheit von NormalizeDouble selbst in Frage stellt.