Fehler, Irrtümer, Fragen - Seite 433

 

Renat, bitte beachten Sie den Antrag #124661 in der SR.

Ich warte seit dem 13. Juni auf eine Antwort.

 
voix_kas:

Renat, bitte beachten Sie den Antrag #124661 in der SR.

Ich warte seit dem 13. Juni auf eine Antwort.

Sie haben also mehr als einmal die richtige Antwort erhalten. Ich habe Ihnen erneut geantwortet.

 
Renat:

Sie haben also mehr als einmal die richtige Antwort erhalten. Ich habe Ihnen erneut geantwortet.

Ich sehe die Antwort nicht in dieser Bewerbung. Der letzte Kommentar darin ist meiner vom 21.06.2011 09:25 (eine wiederholte Erinnerung an die Relevanz der Frage).

Ich dupliziere es hier nur für den Fall:

Verstehe ich das richtig, dass die Begrenzung des Mindestvolumens/der Mindestmenge eines Geschäfts/Auftrags nur für die Eröffnung einer Position relevant ist?
Gelten sie für Geschäfte/Aufträge, die zur Schließung, Erhöhung, Verringerung oder Umkehrung von Positionen führen?
Die Mindestgeschäftsgrenze gilt für alle fünf (5) der oben genannten Szenarien.
Es scheint, dass alle möglichen Szenarien beschrieben werden. Oder gibt es noch andere Szenarien als diese fünf (5)?

Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства сделок
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства сделок
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства сделок - Документация по MQL5
 

Sie haben zweimal eine Antwort erhalten, dann habe ich geantwortet.

Ich antworte noch einmal: Ja, Vollsperrungen fallen nicht unter die Mengenbegrenzungsregel.

 
papaklass:
Geht es darum, die Geschwindigkeit von MQL5 zu erhöhen?
Ja, Code-Optimierung bedeutet genau das.
 
Renat:

Sie wurden zweimal beantwortet, dann habe ich geantwortet.
Ich antworte noch einmal: Ja, vollständige Abschlüsse fallen nicht unter die Volumenbegrenzungsregel.

Renat, verstehen Sie mich nicht falsch. Ich wiederhole meine Frage nicht um der Verwöhnung willen, sondern um sie zu klären.
Bislang decken Ihre Antwort und die Ihrer Kollegen (im SD) 2 (zwei) Szenarien ab: 1) die Eröffnung einer Position und 2) die vollständige Schließung einer Position (wahrscheinlich mit ORDER_FILLING_AON als obligatorischem Element).
Die Ausführung eines Auftrags (Trade) kann zu mindestens drei (3) weiteren Szenarienführen: Erhöhung, Verringerung oder Umkehrung einer Position.
Leider kann ich in den Antworten von MQ keine klare Erklärung für diese drei Szenarien finden. :(

Zur Verdeutlichung hier einige Beispiele(in allen Fällen auf dem Server, Mindestmenge = 1,0; Mindestschrittweite = 0,1):

Beispiel 1 (Positionsverkürzung).
Wir haben eine Long-Position von 1,0. Wir versuchen, die Position vollständig zu schließen (mit ORDER_FILLING_CANCEL). Wir senden einen Verkaufsauftrag von 1,0 Lot. Der Auftrag wird teilweise ausgeführt (0,9 Lots).
Das Ergebnis ist, dass eine offene Long-Position von 0,1 Lot besteht. Daraus können wir schließen, dass die Anforderung des Mindestlosvolumens nicht für das Szenario der Positionsverkürzung gilt.

Beispiel 2 (Umkehrung der Position).
Wir haben eine Long-Position von 0,1 Lot. Ich sende einen Verkaufsauftrag an den Server für das Volumen von 0,2 Lots. Wird der Server diese Bestellung annehmen? (Die Mindestanforderungen an das Grundstück sind wieder nicht erfüllt).

Beispiel 3 (Erhöhung der Position).
Wir haben eine Long-Position von 0,1 Lot. Ich sende einen Kaufauftrag von 0,1 Lot an den Server.

 
voix_kas:


Zur Veranschaulichung hier einige Beispiele(in allen Fällen ist die Mindestmenge = 1,0; Mindestschrittweite = 0,1):

Beispiel 1 (Short-Position).
Wir haben eine Long-Position von 1,0 Lots. Wir versuchen, die Position vollständig zu schließen (mit ORDER_FILLING_CANCEL). Wir senden einen Verkaufsauftrag im Umfang von 1,0 Lot. Der Auftrag wird teilweise ausgeführt (0,9 Lots).
Das Ergebnis ist, dass eine offene Long-Position von 0,1 Lot besteht. Daraus können wir schließen, dass die Anforderung des Mindestlosvolumens nicht für das Szenario der Positionsverkürzung gilt.

Wenn die Position teilweise bei 0,9 schließt (mit einem Auftrag bei 1,0), müssen wir einen weiteren Auftrag senden, um den Restbetrag bei 0,1 zu schließen.

Und wenn der Auftrag über ein externes Gateway ausgeführt wird, ist die Wahrscheinlichkeit groß, dass dort nur das gesamte Volumen von 1,0 Lot auf einmal geschlossen wird und wir es nicht aufteilen können.

Beispiel 2 (Umkehrung der Position).

Wir haben eine Long-Position von 0,1 Lot. Ich sende einen Verkaufsauftrag an den Server für das Volumen von 0,2 Lots. Nimmt der Server diesen Auftrag an? (Die Mindestanforderungen an das Grundstück sind wieder nicht erfüllt).

Es handelt sich nicht um eine vollständige Null-Liquidation, so dass der Antrag abgelehnt wird.


Beispiel 3 (Erhöhung des Positionsvolumens).
Ich habe eine Long-Position von 0,1 Lot. Ich sende einen Kaufauftrag an den Server für das Volumen von 0,1 Lot. Der Server Beispiel für eine solche Bestellung?

Nein, natürlich nicht.

Bitte lesen Sie die Regeln wörtlich und versuchen Sie nicht, Ihre eigenen Bedingungen zu erfinden. Die Regel ist einfach: "Die Volumenbegrenzungsregel kann nicht angewendet werden, wenn eine Position zu NULL liquidiert wird". Diese Regel wurde bereits mehrfach geäußert.


Sie sollten auch berücksichtigen, dass jeder Makler oder jedes Börsen-Gateway seine eigenen, strengeren Regeln für die Volumenkontrolle anwenden kann.

 
Verstehe. Danke für die Klarstellung.
 
IlyaBukalov:

Die maximale Anzahl von Zeilen, zwischen denen öffnende/schließende Klammern hervorgehoben werden, beträgt 128. Diese Einschränkung wurde eingeführt, weil es keinen Sinn macht, öffnende und schließende Klammern zu markieren, die nicht in einen Bildschirm passen. Außerdem hat sich die Leistung von MetaEditor nach Einführung dieser Einschränkung erheblich verbessert.

Es ist sehr lästig, wenn eine Klammer nach 128 Zeilen nicht hervorgehoben wird. Oft muss man zwei oder drei Bildschirme durchblättern, um herauszufinden, wo die Klammer geschlossen ist.
 
voix_kas:

Das ist zwar keine entscheidende Frage, aber immerhin. String-Verkettung. Die Dokumentation beschreibt zwei Funktionen StringAdd und StringConcatenate.

...

Ergebnis:

2011.06.26 19:10:55 test (EURUSD,H1)№1 2012 milliseconds, i = 10000000
2011.06.26 19:11:04 test (EURUSD,H1)#2 8269 Millisekunden, i = 10000000
2011.06.26 19:11:10 test (EURUSD,H1)#3 6661 Millisekunden, i = 10000000

Es stellt sich jedoch heraus, dass die normale Addition schneller ist.

Dieses Beispiel ist falsch.

Die erste Methode sollte "result = result + string1 + string2 + string3;" lauten.

Ich würde auch unterschiedliche Ergebnisse für alle 3 Tests erstellen, da sie sonst nicht unter gleichen Bedingungen starten (ein Teil des Speichers ist bereits belegt).

Noch besser ist es, die Tests in verschiedene Skripte zu packen und sie nacheinander auszuführen.


Ich habe es so verstanden:

1. Länge = 10`000

2011.06.27 02:43:07 sStingTest (EURUSD,M1) №1 2542 Millisekunden, i = 10000
2011.06.27 02:43:05 sStingTest (EURUSD,M1) #2 0 Millisekunden, i = 10000
2011.06.27 02:43:05 sStingTest (EURUSD,M1) #3 0 Millisekunden, i = 10000


2. Länge = 100`000

2011.06.27 02:37:40 sStingTest (EURUSD,M1) #2 47 Millisekunden, i = 1000000

2011.06.27 02:37:39 sStingTest (EURUSD,M1) #3 15 Millisekunden, i = 1000000

Ziel Nr. 1 - hat nicht gewartet


3. Länge = 1`000`000

2011.06.27 02:37:40 sStingTest (EURUSD,M1) #2 780 Millisekunden, i = 1000000

2011.06.27 02:37:39 sStingTest (EURUSD,M1) #3 187 Millisekunden, i = 1000000

Das Ende von Nummer 1 hat nicht stattgefunden.


4. Länge = 10`000`000

2011.06.27 02:48:14 sStingTest (EURUSD,M1) #3 1903 Millisekunden, i = 10000000

Der Fehler "MemoryException: 602492946 bytes not available" begann beim zweiten Test.


Fazit: StringConcatenate ist am schnellsten.


Übrigens hat die StringAdd-Funktion auch ein nicht ganz korrektes Vergleichsbeispiel.

Mein Code zum Testen befindet sich im Anhang.

Dateien: