créer un numéro magique - page 3

Nouveau commentaire
  
//|                                                      This_EA.mq4 |
//|                      Copyright © 2010, MetaQuotes Software Corp. |
//|                                        http://www.metaquotes.net |
//+------------------------------------------------------------------+

#define This_EA  101
#define That_EA  102
#define Other_EA 103 // put this list of ea names to each of your ea's header, or...
                     // .. alternatively you can use a number suffix to your ea's file name 
                     // so it can be identified with --> StringSubstr(WindowExpertName(),x,y);
double This_EA_qty;
string magic_prefix;

int init()
  {

   if(GlobalVariableGet(This_EA_qty) >= 0.0){
            GlobalVariableSet("This_EA_qty", This_EA_qty + 1);
   }
   magic_prefix = StringConcatenate(This_EA, DoubleToStr(This_EA_qty,0));

   return(0);
  }

int deinit()
  {

      GlobalVariableSet("This_EA_qty", This_EA_qty - 1);
   
   return(0);
  }

int start()
  {
      double lots, SL, TP; int slip, time_stamp ;
      bool BuyCondition;
   
      if( BuyCondition == true )
      {
         time_stamp  = TimeCurrent(); 
         string magic_name = StringConcatenate(magic_prefix, time_stamp );
         int magic = StrToInteger(magic_name);
         
                                      // Integers range from -2147483648 to 2147483647
                                      // the resulting magic integer would most probably exceed that 
                                      // so we cut the number returned with TimeCurrent() short with 
                                      // MathMod(time_stamp,x) x being years, months not necessary for 
                                      // magic unique-ness. I don't include this calculation, 
                                      // since I'm short in time for testing it...
      
      
         OrderSend(Symbol(),0, lots, Ask, slip, SL, TP, NULL, magic, 0, CLR_NONE);
      }
//----
   return(0);
  }
//+------------------------------------------------------------------+
Cela prend un peu plus de temps que je ne le pensais ...
edit : GVget condition != -1.0 to >= 0.0 ; edit
 
cameofx:
[...] ça prend un peu plus de temps que prévu...

Cela devient de plus en plus une répétition (excusez le jeu de mots) du sujet précédent que j'ai déjà mentionné : https://www.mql5.com/en/forum/120034. Tout ce qui implique des variables globales soulève des problèmes de sauvegarde et de reprise après sinistre. Si les échanges doivent être déplacés en urgence vers un nouveau serveur, il faut soit disposer d'une sauvegarde récente de gvariables.dat, soit que l'utilisateur soit en mesure de recréer les variables globales manuellement.

Je n'ai pas étudié votre code de près, mais je ne sais pas non plus ce qui se passe s'il y a plusieurs copies de l'EA et que MT4 est ensuite redémarré. Il semble que le code suppose que les EA seront automatiquement rechargées dans l'ordre dans lequel elles ont été initialement chargées manuellement. En d'autres termes, plusieurs copies de l'EA peuvent obtenir des valeurs This_EA_qty différentes au fil des redémarrages, et je ne vois pas comment elles peuvent identifier correctement leurs ordres historiques dans la liste MT4. Mais je peux me tromper à ce sujet.

 
cameofx:
prend un peu plus de temps que je ne le pensais ...
edit : GVget condition != -1.0 to >= 0.0
// TimeCurrent() in seconds since 1970 would most probably exceed that

TimeCurrent() retourne un entier de 32 bits. Le type datatime est un alias pour le type int, int est aussi un entier de 32 bits.


L'autre chose que je ne comprends pas dans votre code est pourquoi vous utilisez un MN différent pour chaque transaction ouverte ? C'est le contraire de ce à quoi les MN sont destinés. L'idée d'un MN est que vous pouvez identifier toutes les transactions d'un certain EA en regardant simplement le MN. Quelle est la raison de la partie aléatoire du MN ? A quoi ressemblerait un code dans votre EA qui fermerait toutes les transactions ouvertes de cet EA ou qui suivrait tous les stops de cet EA ?
 
Si je comprends bien, votre solution pour éviter que deux experts différents aient accidentellement le même identifiant consiste à placer tous les identifiants des experts dans l'en-tête de chaque expert. C'est une sorte de douleur dans le cul... Même si vous mettez cette partie dans un fichier include, vous aurez toujours besoin de recompiler tous les experts pour chaque nouvel expert que vous faites.

La question de la persistance est toujours là. Je ne sais pas comment cela pourrait fonctionner correctement après un redémarrage du terminal ou après avoir changé de terminal...
 
jjc:

Ce sujet devient de plus en plus une répétition (excusez le jeu de mots) du sujet précédent que j'ai déjà mentionné : https://www.mql5.com/en/forum/120034. Tout ce qui implique des variables globales soulève des problèmes de sauvegarde et de reprise après sinistre. Si les échanges doivent être déplacés en urgence vers un nouveau serveur, il faut soit disposer d'une sauvegarde récente de gvariables.dat, soit que l'utilisateur soit en mesure de recréer les variables globales manuellement.

Je n'ai pas étudié votre code de près, mais je ne sais pas non plus ce qui se passe s'il y a plusieurs copies de l'EA et que MT4 est ensuite redémarré. Il semble que le code suppose que les EA seront automatiquement rechargées dans l'ordre dans lequel elles ont été initialement chargées manuellement. En d'autres termes, plusieurs copies de l'EA peuvent obtenir des valeurs This_EA_qty différentes au fil des redémarrages, et je ne vois pas alors comment ils identifient correctement leurs ordres historiques dans la liste MT4. Mais je peux me tromper.

C'est le genre de commentaires que j'attends... merci à gordon, 7bit et jjc...

vos réponses nécessitent une réflexion... mais pour répondre rapidement :

- si l'expert This_EA est déjà attaché une fois sur un autre graphique, magic_number aurait alors la valeur de : 101-1-time_stamp (tiret pour plus de clarté)

- l'information contenue serait 101 - l'id de l'expert ; 1 - la quantité de This_EA opérant à ce moment ; time_stamp - l'heure de l'OrderSend

- nous pouvons alors l'analyser avec StringSubStr et savoir qu'un ordre particulier a été ouvert par This_EA alors qu'il y avait 1 autre This_EA attaché.

 
7bit:

TimeCurrent() renvoie un entier de 32 bits. Le type datatime est un alias pour le type int, int est également un entier de 32 bits.


L'autre chose que je ne comprends pas dans votre code est pourquoi vous utilisez un MN différent pour chaque trade ouvert ? C'est le contraire de ce à quoi les MN sont destinés. L'idée d'un MN est que vous pouvez identifier toutes les transactions d'un certain EA en regardant simplement le MN. Quelle est la raison de la partie aléatoire du MN ? A quoi ressemblerait un code dans votre EA qui fermerait toutes les transactions ouvertes de cet EA ou qui suivrait tous les stops de cet EA ?

Désolé, ce que je voulais dire c'est que l'int magic_name résultant dépasserait cette allocation. Je vais déplacer le commentaire dans le code en conséquence.

Pour égaliser notre perception. Je propose les conditions suivantes pour ce numéro magique "automatisé". Le MN devrait avoir les éléments suivants :

- Vous pouvez identifier avec quel EA - cet ordre particulier avec ledit MN - était ouvert.

- Un EA contenant cette technique - s'il est attaché à de nombreux (plus de 1) EA ne générerait pas le même numéro magique si ces EA ouvrent des ordres simultanément en dehors d'un intervalle de 1 seconde.

- Ainsi, il n'y aurait pas de conflit dans le traitement des ordres, mais en même temps, l'origine du MN peut toujours être tracée.

- S'il vous plaît, ajoutez si ma liste n'est pas complète...

 
cameofx:
- les informations contenues seraient 101 - id de l'expert ; 1 - quantité de This_EA opérant à ce moment ; time_stamp - heure de l'OrderSend

- nous pouvons alors le scanner avec StringSubStr et savoir qu'un ordre particulier a été ouvert par This_EA alors qu'il y avait 1 autre This_EA attaché.

Mais à quoi sert la partie temps dans le MN ? Pourquoi ne pas utiliser uniquement les numéros d'EA et ne pas utiliser de substrat ? L'utilisation de substr nécessiterait la conversion de l'entier en chaîne de caractères, puis quelques opérations de chaîne de caractères et une comparaison de chaîne de caractères, la partie temps du MN est jetée car elle n'est jamais nécessaire. Les opérations sur les chaînes de caractères avec des entiers ont généralement tendance à faire figure d'amateurisme car, dans la plupart des cas, elles pourraient être mieux résolues en codant les informations dans différents bits du mot de 32 bits et en utilisant des opérations sur les bits pour les manipuler ou les vérifier, ce qui serait beaucoup plus rapide et plus élégant.

Pourquoi ne pas simplement utiliser une valeur int (EA-instance-unique) pour le mn et utiliser une simple comparaison d'entiers pour comparer soit le nombre entier soit certains de ses bits ?

Par exemple, laissez les 28 premiers bits être l'ID et les quatre derniers bits un nombre de 0 à 15 pour identifier les différents types de transactions (par exemple, s'il peut ouvrir 3 types d'ordres différents : initial, niveau 1, niveau 2 et couverture).

ID = hash & 0xFFFFFFF0  // this has the 4 low bits always zero


// generate the mn for level 1 trades
MN = (ID + 1);
OrderSend(..., MN, "level 1");


// generate the mn for hedge trades
MN = (ID + 15);
OrderSend(..., MN, "hedge the whole mess");


// this strategy may not make any sense, only to illustrate the code:
// close the hedge trades and trail the stops of all levels
for(...){
   if (OrderMagicNumber() & 0xFFFFFFF0 == ID){  // this trade belongs to us
      if (OrderMagicNumber() & 0x0000000F == 15){ // this is a hedge trade
         OrderClose(...)
      }else{ // this is one of the other levels
         Trail(OrderTicket());
      }
   }
}

// or even easier:
MN = (ID + 15); // all our hedge trades have this MN
for(...){
   if (OrderMagicNumber() == MN){
      OrderClose(...)
   }
}
 
gordon:
Si je comprends bien, votre solution pour éviter que deux experts différents aient accidentellement le même ID est de mettre tous les ID des experts dans l'en-tête de chaque expert. C'est un peu casse-gueule... Même si vous mettez cette partie dans un fichier include, vous aurez toujours besoin de recompiler tous les experts pour chaque nouvel expert que vous faites.

La question de la persistance est toujours là. Je ne sais pas comment cela pourrait fonctionner correctement après un redémarrage du terminal ou après avoir changé de terminal...

Non, vous n'avez pas :) veuillez lire les commentaires dans le code concernant WindowExpertName().

Si vous l'appelez à partir d'un expert, il récupérera le nom du fichier expert/script/indicateur sans le ".mq4" ou ".ex4". Vous n'avez pas besoin de mettre d'include, nommez simplement vos EAs en conséquence.

PS : désolé pour la réponse spammy :)

 
7bit:

Mais à quoi sert la partie temps dans le MN ? Pourquoi ne pas utiliser uniquement les chiffres de l'EA et ne pas utiliser le substrat ? L'utilisation de substr nécessiterait la conversion de l'entier en chaîne de caractères, puis quelques opérations de chaîne de caractères et une comparaison de chaîne de caractères, la partie temps du MN est jetée car elle n'est jamais nécessaire. Les opérations sur les chaînes de caractères avec des entiers ont généralement tendance à ressembler à de l'amateurisme parce que, dans la plupart des cas, elles pourraient être mieux résolues en codant les informations dans différents bits du mot de 32 bits et en utilisant des opérations sur les bits pour les manipuler ou les vérifier, ce qui serait beaucoup plus rapide et plus élégant.

Pourquoi ne pas simplement utiliser une valeur int (EA-instance-unique) pour le mn et utiliser une simple comparaison d'entiers pour comparer soit le nombre entier soit certains bits de celui-ci ?

Par exemple, laissez les 28 premiers bits être l'ID et les quatre derniers bits un nombre de 0 à 15 pour identifier les différents types de transactions (par exemple, s'il peut ouvrir 3 types d'ordres différents : initial, niveau 1, niveau 2 et couverture).


hmm... J'utilise la partie temps car je pensais que le MN pour chaque ordre ouvert par un EA doit être unique par rapport aux autres ordres ouverts au même moment avec le même EA sur différents graphiques.

La prémisse serait la suivante : si un EA ouvre deux (ou plus) ordres simultanément avec le même numéro magique, ils ne peuvent pas avoir le même MN, sinon il y aurait un conflit dans le traitement des ordres et/ou l'identification des ordres.

l'identification des ordres... j'ai peut-être confondu par erreur avec la saisie d'un OrderTicket (ou pas ?).

- L'incorporation de la stratégie au MN serait la prochaine étape, naturellement.

- Je vois que vos compétences me dépassent de plusieurs années-lumière : )). Je n'ai pas encore la capacité d'optimiser les opérations, c'est pourquoi j'ai posté ceci... Maintenant je sais que la vérification avec des opérations par bit serait plus rapide.

Merci. Je pourrais avoir besoin de vous demander des explications plus tard :))))

 
cameofx:

hmm... J'utilise la partie temps parce que je pensais que le MN pour chaque ordre ouvert par un EA doit être unique par rapport aux autres ordres

Non, ils peuvent être ce que vous voulez. tout comme le commentaire. voyez-les comme une sorte de commentaire numérique. Toutes les transactions manuelles ouvertes avec l'interface utilisateur normale de MT4 auront le numéro magique 0, de sorte que vous pouvez par exemple boucler sur tous les ordres et fermer/supprimer toutes les transactions manuelles et les ordres tout en laissant toutes les transactions EA intactes.

Tous mes EAs créent leur propre numéro, unique à (nom de l'EA + symbole + timeframe), c'est pourquoi j'ai dépensé tant d'efforts pour trouver une bonne et facile fonction de hachage pour créer ce numéro. Le hachage est même si bon que je peux facilement couper les derniers bits de ce hachage pour faire de la place pour les sous-numéros (si j'en ai besoin, mais j'en ai rarement besoin) et il serait encore assez sûr contre les collisions.

Mais la plupart de mes EA utilisent directement le hash et n'ont pas de sous-numérotation car ils n'ont qu'un seul type de transactions et traitent toutes leurs transactions de manière identique.

Pour identifier de façon unique un certain ordre, il y a toujours le numéro de ticket.

12345
Nouveau commentaire