Erreurs, bugs, questions - page 433

 

Renat, si vous pouviez s'il vous plaît prêter attention à la demande #124661 dans le SR.

J'attends une réponse depuis le 13 juin.

 
voix_kas:

Renat, si vous pouviez s'il vous plaît prêter attention à la demande #124661 dans le SR.

J'attends une réponse depuis le 13 juin.

On vous a donc donné la bonne réponse à plusieurs reprises. Je vous ai encore répondu.

 
Renat:

On vous a donc donné la bonne réponse plus d'une fois. Je vous ai encore répondu.

Je ne vois pas la réponse dans cette application. Le dernier commentaire est le mien, datant de 2011.06.21 09:25 (un rappel répété de la pertinence de la question).

Je le duplique ici juste au cas où :

Ai-je bien compris que la limite du volume/lot minimum d'une transaction/ordre ne concerne que l'ouverture d' une position ?
S'appliquent-ils aux transactions/ordres entraînant la fermeture, l'augmentation, la diminution ou l'inversion de postes?
La limite de l'opération minimale s'applique aux cinq (5) scénarios ci-dessus.
Il semble que tous les scénarios possibles soient décrits. Ou existe-t-il d'autres scénarios que ces cinq (5) ?

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

On vous a répondu deux fois, puis j'ai répondu.

Je réponds à nouveau : oui, les fermetures complètes ne sont pas couvertes par la règle de la limite de volume.

 
papaklass:
Parle-t-on d'augmenter la vitesse de MQL5 ?
Oui, l'optimisation du code signifie exactement cela.
 
Renat:

On vous a répondu deux fois, puis j'ai répondu.
Je réponds à nouveau : oui, les clôtures complètes ne sont pas soumises à la règle de la limite de volume.

Renat, ne vous méprenez pas. Je répète ma question non pas pour la dorloter, mais pour la clarifier.
Jusqu'à présent, votre réponse et celle de vos collègues (dans le SD) couvre 2 (deux) scénarios : 1) ouverture d'une position et 2) fermeture complète d'une position (probablement avec ORDER_FILLING_AON étant obligatoire).
L'exécution d'un ordre (trade) peutdonner lieu à au moins trois (3) autres scénarios : augmenter, diminuer ou inverser une position.
Malheureusement, je ne trouve aucune explication claire de ces trois scénarios dans les réponses de MQ. :(

Pour plus de clarté, voici quelques exemples(dans tous les cas sur le serveur, lot minimum = 1,0; pas minimum = 0,1) :

Exemple n°1 (raccourcissement de la position).
Nous avons une position longue de 1,0. Nous essayons de fermer complètement la position (en utilisant ORDER_FILLING_CANCEL). Nous envoyons un ordre de vente de 1.0 lot. L'ordre est partiellement exécuté (0.9 lots).
Le résultat est qu'il y a une position longue ouverte de 0,1 lot. Nous pouvons donc conclure que l'exigence de volume minimum de lot ne s'applique pas au scénario de raccourcissement des positions.

Exemple 2 (inversion de position).
Nous avons une position longue de 0.1 lot. J'envoie un ordre de vente au serveur pour le volume de 0.2 lots. Le serveur acceptera-t-il cette commande ? (Les exigences minimales en matière de lot ne sont pas respectées à nouveau).

Exemple 3 (augmentation de la position).
Nous avons une position longue de 0.1 lot. J'envoie au serveur un ordre d'achat de 0.1 lot.

 
voix_kas:


Pour illustrer, voici quelques exemples(dans tous les cas, le lot minimum = 1,0; le pas minimum = 0,1) :

Exemple 1 (position courte).
Nous avons une position longue de 1.0 lots. Nous essayons de fermer complètement la position (en utilisant ORDER_FILLING_CANCEL). Nous envoyons un ordre de vente dans le volume de 1.0 lot. L'ordre est partiellement exécuté (0.9 lots).
Le résultat est qu'il y a une position longue ouverte de 0,1 lot. Nous pouvons donc conclure que l'exigence de volume minimum de lot ne s'applique pas au scénario de raccourcissement des positions.

Si la position se ferme partiellement à 0,9 (avec un ordre à 1,0), nous devrons alors envoyer un autre ordre pour fermer le solde à 0,1.

Et si l'ordre est exécuté par une passerelle externe, il est fort probable qu'elle ne fermera que la totalité du volume de 1,0 lot en une seule fois, sans nous permettre de le diviser.

Exemple 2 (inversion de position).

Nous avons une position longue de 0.1 lot. J'envoie un ordre de vente au serveur pour le volume de 0.2 lots. Le serveur accepte-t-il cette commande ? (Les exigences minimales en matière de lot ne sont pas respectées à nouveau).

Il ne s'agit pas d'une liquidation complète d'une position à zéro, la demande sera donc rejetée.


Exemple 3 (augmentation du volume de la position).
J'ai une position longue de 0,1 lot. J'envoie un ordre d'achat au serveur pour le volume de 0.1 lot. Le serveur a-t-il un exemple d'un tel ordre ?

Bien sûr que non.

Veuillez lire les règles littéralement et n'essayez pas d'inventer vos propres conditions. La règle est simple : "la règle de limite de volume ne peut s'appliquer lorsqu'une position est liquidée à ZERO". Cette règle a été exprimée à de nombreuses reprises.


Vous devez également tenir compte du fait que tout courtier ou toute passerelle d'échange peut utiliser ses propres règles de contrôle du volume, plus strictes.

 
Je vois. Merci pour la clarification.
 
IlyaBukalov:

Le nombre maximum de lignes entre lesquelles les parenthèses ouvrantes/fermantes seront mises en évidence est de 128. Cette limitation a été introduite parce qu'il est inutile de mettre en évidence les parenthèses ouvrantes et fermantes qui ne tiennent pas dans un seul écran. Par ailleurs, les performances de MetaEditor ont considérablement augmenté après l'introduction de cette restriction.

Il est très gênant qu'une parenthèse ne soit pas mise en évidence après 128 chaînes de caractères, il faut souvent faire défiler deux ou trois écrans pour trouver où la parenthèse est fermée.
 
voix_kas:

Pas une question cruciale, mais quand même. Concaténation de chaînes de caractères. La documentation décrit deux fonctions StringAdd et StringConcatenate.

...

Résultat :

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

Il s'avère cependant que l'addition normale est plus rapide.

Cet exemple est incorrect.

La première méthode devrait avoir "result = result + string1 + string2 + string3 ;"

Je ferais aussi un résultat différent pour les 3 tests, sinon ils ne démarreront pas dans les mêmes conditions (une partie de la mémoire est déjà allouée).

Mieux encore, placez les tests dans différents scripts et exécutez-les de manière séquentielle.


Je vois ça comme ça :

1. longueur = 10`000

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


2. longueur = 100`000

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

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

Arrivée #1 - n'a pas attendu


3. longueur = 1`000`000

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

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

La fin du numéro 1 n'a pas eu lieu.


4. longueur = 10`000`000

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

MemoryException : 602492946 bytes not available" l'erreur a commencé au deuxième test.


Conclusion : StringConcatenate est le plus rapide.


D'ailleurs, la fonction StringAdd a aussi un exemple de comparaison pas très correct.

Mon code pour le tester est dans le trailer.

Dossiers :