![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
Frage an die Entwickler:
Warum ist es im Prüfgerät nicht möglich, das Feld der Struktur zu erhalten?
MqlTradeResultprice;// Preis in einem Handel, bestätigt durch den Broker? Es ergibt 0.
In der Demo funktioniert es gut.
Gibt es einen Zusammenhang zwischen der Listenstruktur der Zeitrahmen und den Sichtbarkeitskennzeichen der Objekte (denn auch die Länge der Listen ist unterschiedlich: 22 gegenüber 23)? Im Allgemeinen geht es mir darum, die Sichtbarkeit von Objekten auf Zeitrahmen in einem Zyklus mit bestimmten Grenzen effizient und kompakt zuzuordnen, anstatt Flaggen manuell aufzulisten und zusammenzufassen. Welche Logik ist zu verwenden, wenn ein beliebiger Zeitrahmen zufällig ausgewählt wird, ein grafisches Objekt darauf aufgebaut wird und es auf allen Zeitrahmen, die nicht älter als der aktuelle sind (d.h. der, auf dem es aufgebaut wurde), sichtbar sein soll? Der Algorithmus sollte allgemeingültig sein und nicht nur für einen bestimmten Fall gelten. Die Indexkorrelation ist bereits gestört, es gibt nicht einmal eine Indexübereinstimmung. Das Parsen von Namensstrings und der Vergleich scheitert erneut an der Unmöglichkeit, Strings im Falle von Sichtbarkeitskonstanten zu verarbeiten. Bislang ist eine komplizierte, vage und sehr krumme Umsetzung zu beobachten.
Natürlich gibt es eine Korrelation, aber sie ist so implizit, dass man nur <Sichtbarkeitskennzeichen> = F(<Zeitrahmen>) schreiben kann:
x100intraday:
Welche Logik ist zu verwenden, wenn wir einen beliebigen Zeitrahmen nehmen, ein grafisches Objekt darauf aufbauen und seine Sichtbarkeit auf allen Zeitrahmen zulassen müssen, die nicht älter sind als der aktuelle (d. h. der, auf dem es aufgebaut wurde)?
wenn es sich nicht um einen Checker handelt)
Betrachten Sie TF[i], setzen Sie Sichtbarkeit[i]...
oder Sichtbarkeit=(int)(MathPow(2,i+1)-1);
Wenn Sie es brauchen, dann ist es kein Schachbrett)
Betrachten Sie TF[i], setzen Sie Sichtbarkeit[i]...
oder Sichtbarkeit=(int)(MathPow(2,i+1)-1);
Danke für die Sichtbarkeitsformel - vielleicht werde ich sie anpassen. Aus den Werten der Zeitrahmen war ersichtlich, dass es sich um ein gewisses Maß handelt, aber ich habe nicht versucht, die Formel selbst zu rekonstruieren.
Wird -1 benötigt? Generell scheint Visibility[] mit falschen Werten gefüllt zu sein, eigentlich sollte es überall ohne -1 sein, d.h.: 1, 2, 4, 8, 16...
Natürlich gibt es eine Beziehung, aber sie ist so implizit, dass die einzige Möglichkeit, <visibility_flag>=F(<timeframe>) zu schreiben, darin besteht, es so zu machen:
Danke, elegant. Das ist genau das, was ich versucht habe, abgesehen von der Verschiebung selbst, die genau das ist, was ich vermisst habe.
Und am Ende habe ich tatsächlich die Frage der Berechnung der Flaggenwerte bei jeder Umdrehung der Regressionsschleife über ein Array von _p_int Zeitrahmen (am Ende wird etwas in Flaggen hinzugefügt werden müssen), nicht nur auf dem aktuellen. Nun, indem man den Wert der Sichtbarkeitsfahne im aktuellen Zeitrahmen verschiebt und dann bei jeder Drehung von i-- sollte sich irgendwo etwas ändern... Hier muss entweder die Potenzierungsformel angewandt oder das gleiche Verschiebungsprinzip angewendet werden. Ich habe noch nicht herausgefunden, wie...
... Obwohl, ja, es ist eine Funktion mit TF-Argument - ich werde versuchen, eine Schleife zu machen...
Aber es ist wieder falsch. Lassen Sie mich das erklären. In dem Beispiel gibt es statische ENUM_TIMEFRAMES _p_int[] für 21 Elemente, aber hier ist, was ich will: Ich habe bereits ein solches Array, aber es kann von beliebiger Länge sein. Es handelt sich um ein Array, das die Zeitrahmen enthält, auf denen etwas aufgebaut werden soll, die aber auch auf allen niedrigeren Zeitrahmen sichtbar sein sollen und keines der Arrays separat oder zusätzlich zu den bestehenden mit ihnen gefüllt wird. Hier erwähne ich also die Notwendigkeit, die Flaggen des aktuellen und aller niedrigeren Zeitrahmen zu berechnen und sie in der Regressionsschleife on the fly zu summieren, wobei vom aktuellen Zeitrahmen getanzt wird. Der Trick besteht darin, nicht ein komplettes Array von voreingestellten Werten für irgendetwas zu erstellen (auch nicht für Zeitrahmen oder Sichtbarkeitsflags) und damit herumzuspielen, sondern in meinem Kopf für jeden Zug nur das unvollständige Array von voreingestellten Zeitrahmen zu berechnen.
Ich mache eine Weile weiter und wenn ich nicht weiterkomme, frage ich nach.
Warum habe ich es nicht eilig, (int)(MathPow(2,i+1)-1) oder ((int)1)<<i zu verwenden... Wenn i vorhanden ist, können Sie es einfach durch eine Schleife ersetzen und ausführen... Aber ist das, genau wie bei der Multiplikation und der Verschiebung, immer sicher? Angenommen, die Entwickler fügen neue Zeitrahmen hinzu, gerät dann nicht die gesamte Logik aus den Fugen? Um es gleich vorwegzunehmen - im Beispiel mit der Verschiebung erwarten wir, dass die aktuelle Periode mit der voreingestellten übereinstimmt:
if(period==_p_int[i])
Selbst wenn also im realen Fall einige Zeitspannen aus der theoretisch vollständigen Abfolge wegfallen oder diese Abfolge von den Entwicklern erweitert wird, sollte die Logik nicht ins Wanken geraten. Aber wenn wir uns auf die reine Mathematik verlassen und den Zyklus nur formelhaft von Grenze zu Grenze durchlaufen, ohne auf das mögliche Vorhandensein oder Fehlen neuer Zeitrahmen zu achten, dann würden wir früher oder später beim nächsten Build eine Schieflage bekommen...Warum habe ich es nicht eilig, (int)(MathPow(2,i+1)-1) oder ((int)1)<<i zu verwenden... Wenn i vorhanden ist, können Sie es einfach durch eine Schleife ersetzen und ausführen... Aber ist das, genau wie bei der Multiplikation und der Verschiebung, immer sicher? Angenommen, die Entwickler fügen neue Zeitrahmen hinzu, gerät dann nicht die gesamte Logik aus den Fugen? Nur mal so am Rande: Im Beispiel mit der Verschiebung erwarten wir, dass die aktuelle Periode die gleiche ist wie die voreingestellte:
Selbst wenn also im realen Fall einige Zeitspannen aus der theoretisch vollständigen Abfolge wegfallen oder diese Abfolge von den Entwicklern erweitert wird, sollte sich die Logik nicht einschleichen. Aber wenn wir uns auf die reine Mathematik verlassen und den Zyklus nach der Formel von Grenze zu Grenze durchlaufen, ohne auf das mögliche Vorhandensein oder Nichtvorhandensein neuer Zeitrahmen zu achten, dann würden wir früher oder später bei der nächsten Erstellung eine Schieflage erhalten...Unsere Bedenken sind sehr berechtigt. Der obige Code rechtfertigt die Tatsache, dass das gesetzte Sichtbarkeitskennzeichen eigentlich ein Makro ist.
Es wäre korrekter, sie zu bearbeiten:
Danke für die Sichtbarkeitsformel - vielleicht werde ich sie anpassen. Anhand der Werte in den Zeitrahmen konnte ich erkennen, dass es sich um einen gewissen Grad handelt, aber ich habe nicht versucht, die Formel selbst zu rekonstruieren.
Ist -1 wirklich notwendig? Tatsächlich scheint Visibility[] falsch ausgefüllt zu sein, eigentlich sollte es überall ohne -1 sein, d.h. 1, 2, 4, 8, 16...
1,2,4 usw. - Sichtbarkeit des Objekts in einem Zeitrahmen. =MathPow(2,i);
auf aktuelle und kleinere 1, 1+2, 1+2+4, 1+2+4+8 usw., taki =MathPow(2,i+1)-1;
Im Binärcode ist das deutlicher.
Die Befürchtungen sind sehr berechtigt. Der obige Code rechtfertigt nur die Tatsache, dass der Satz von Sichtbarkeitskennzeichen eigentlich ein Makro ist.
Der richtige Weg ist, sie zu verarbeiten:
Das ist im Prinzip dasselbe. Wenn Sie Änderungen in der Liste eines tf vornehmen, müssen Sie den Code bearbeiten.
Ich kann mir keine allgemeingültige Lösung vorstellen, und ich vermute, dass es theoretisch unmöglich ist, mögliche Änderungen vorherzusehen.
x100intraday:
Aber wieder falsch. Lassen Sie mich das erklären. Im Beispiel wird statisches ENUM_TIMEFRAMES _p_int[] für 21 Elemente erstellt, aber ich möchte folgendes: Ich habe bereits ein solches Array, aber es kann eine beliebige Länge haben. Es handelt sich um ein Array, das die Zeitrahmen enthält, auf denen etwas aufgebaut werden soll, die aber auch auf allen niedrigeren Zeitrahmen sichtbar sein sollen und keines der Arrays separat oder zusätzlich zu den bestehenden mit ihnen gefüllt wird. Hier erwähne ich also die Notwendigkeit, die Flaggen des aktuellen und aller niedrigeren Zeitrahmen zu berechnen und sie in der Regressionsschleife on the fly zu summieren, wobei vom aktuellen Zeitrahmen getanzt wird. Der Trick besteht darin, nicht ein komplettes Array von voreingestellten Werten für irgendetwas zu erstellen (auch nicht für Zeitrahmen oder Sichtbarkeitsflags) und eine Schleife durch diese zu ziehen, sondern bei jedem Zug nur das unvollständige Array der voreingestellten Zeitrahmen zu berechnen.
Nein, das werden Sie nicht. Die Entsprechung von Zeitrahmen und Sichtbarkeit muss definiert werden. Oder zwei entsprechende Arrays oder Schalter.
+Array mit den benötigten TFs, +init berechnen Sie die Objektsichtbarkeit für jede verwendete TF. Etwa so...)
Ich kann nicht herausfinden, was los ist.
2011.12.29 01:16:07 Kern 1 2011.09.26 02:54:13 o_O ((((( stopcal = 1.54508 VirtualSL = 1.53378
2011.12.29 01:16:07 Kern 1 2011.09.26 02:54:12 o_O ((((( stopcal = 1,54507 VirtualSL = 1,53378
2011.12.29 01:16:07 Kern 1 2011.09.26 02:54:12 o_O ((((( stopcal = 1,54508 VirtualSL = 1,53378
Ich habe mir das Hirn zermartert, aber ich verstehe nicht, was los ist?
Es handelt sich um einen Fehler im Optimierer des Compilers. Vielen Dank für Ihre Nachricht, wir werden das Problem beheben.
Der Fehler tritt bei der folgenden Konstruktion auf
VirtualSL!=0.0 kann aus dem zweiten Teil der ersten if-Bedingung entfernt werden,da dieser Ausdruck immer wahr ist, nachdem der erste Teil überprüft wurde. Der Optimierungsfehler wird verschwinden.Korrigiert, der Fix wird im nächsten Build enthalten sein.