[ARCHIVE] Toute question de débutant, afin de ne pas encombrer le forum. Professionnels, ne passez pas à côté. Nulle part sans toi - 3. - page 169

Nouveau commentaire
 

splxgf:

DhP:

Comment " alléger " ce cycle ? Il faut beaucoup de temps pour compter.
 if(iHigh(NULL,60,i)>LOWprice && LOWprice>iLow(NULL,60,i)) if(LOWprice> bid) CountH++ else CountL++;

Ou mieux encore, comme ça :

 if(iHigh(NULL,60,i)>LOWprice) if(LOWprice>iLow(NULL,60,i)) if(LOWprice> bid) CountH++ else CountL++;

Il y a aussi l'idée de former un tableau de valeurs hautes et basses. Peut-être que cela accélérera un peu les choses ?

 
abolk:


la commande est sélectionnée https://docs.mql4.com/ru/trading/OrderSelect - bouclage ou sélection par ticket

la fonction Order*() recherche alors le paramètre d'ordre correspondant.

Désolé pour les questions brutales, mais :

Si nous utilisons MODE_HISTORY comme source de données pour la sélection dans la fonction OrderSelect , c'est-à-dire que l'ordre est sélectionné parmi les ordres fermés et supprimés, alors comment trouver le numéro de l'ordre qui a été fermé en dernier ? Comment ces commandes sont-elles numérotées dans le programme ? Est-ce du dernier au premier ou vice versa ?

 
Xaoss1990:

Désolé, bien sûr, pour les questions stupides, mais.. :

si MODE_HISTORY est utilisé dans la fonction OrderSelect comme source de données, c'est-à-dire que l'ordre est sélectionné parmi les ordres fermés et supprimés, comment puis-je trouver le numéro de l'ordre qui a été fermé en dernier ? Comment ces commandes sont-elles numérotées dans le programme ? Est-ce du dernier au premier ou vice versa ?


il existe de nombreuses questions de ce type sur Internet

http://forum.alpari.ru/showthread.php?t=27708

 
Xaoss1990:

Désolé pour les questions stupides, mais :

si MODE_HISTORY est utilisé dans la fonction OrderSelect comme source de données pour la sélection, c'est-à-dire que l'ordre est sélectionné parmi les ordres fermés et supprimés, comment puis-je trouver le numéro de l'ordre qui a été fermé en dernier ? Comment ces commandes sont-elles numérotées dans le programme ? Est-ce du dernier au premier ou vice versa ?


La fonction permettant de trouver le dernier des ordres fermés est similaire à la fonction permettant de trouver l'ordre avec le temps de fermeture maximum.
 
LazarevDenis:


beaucoup de ces questions ont déjà été posées sur internet

http://forum.alpari.ru/showthread.php?t=27708

О ! Je l'ai trouvé, merci :

OrderSelect(HistoryTotal()-1,SELECT_BY_POS,MODE_HISTORY) ;

C'est vrai, n'est-ce pas ? !

 
DhP:

Comment " alléger " ce cycle ? Le calcul est très long.

Spellbound :

   INS = True;
   
   for (int i=1; i<=6000; i++)
   {
      if (INS)
      {
         if (LOWprice > iHigh(NULL,60,i))
         {
            INS = False;
            UPP = True;
            LOW = False;
            continue;
         }
         if (LOWprice < iLow (NULL,60,i))
         {
            INS = False;
            UPP = False;
            LOW = True;
            continue;
         }
      }
      else
      {
         if (UPP)
            if (LOWprice > iHigh(NULL,60,i))
               continue;
            else
            if (LOWprice < iLow (NULL,60,i))
            {
               // INS = "False"
               UPP = False;
               LOW = True;
               continue;
            }
         if (LOW)
            if (LOWprice < iLow (NULL,60,i))
               continue;
            else
            if (LOWprice > iHigh(NULL,60,i))
            {
               // INS = "False"
               UPP = True;
               LOW = False;
               continue;
            }
         
         INS = True;
      }
      
      if (LOWprice > Bid)
         CountH++;
      else
         CountL++;
   }

La logique veut que le prix soit plus souvent à l'extérieur des barres historiques qu'à l'intérieur.

INS = Inside.

J'ai vérifié l'exactitude du code sur un dépliant. Je n'ai pas vérifié la vitesse du code. Mais je suis sûr que les variables booléennes offrent un bon avantage.

 
MaxZ:

Spellbound :

La logique est que le prix est plus souvent à l'extérieur des barres historiques qu'à l'intérieur.

INS = "Inside".

P.S. : J'ai vérifié l'exactitude du code sur une feuille de papier. Je n'ai pas vérifié la vitesse du code. Mais je suis sûr que les variables booléennes offrent un bon avantage.


Oui.

Vous devez être tellement tordu pour transformer trois lignes de code claires en code difficile à comprendre.

Si vous aviez eu l'idée de diviser le chèque iLow, iHigh, vous auriez pu le faire tout de suite :

          if(LOWprice> bid)if(iHigh(NULL,60,i)>LOWprice)if( LOWprice>iLow(NULL,60,i))CountH++;  
          if(LOWprice<=bid)if(iHigh(NULL,60,i)>LOWprice)if( LOWprice>iLow(NULL,60,i))CountL++;
et ne touchez à rien
  
      int HourPrices[20000];     
      for(int i=1; i<=6000; i++)
	 for (double cPrice=iLow(NULL,60,i);cprice<=iHigh(NULL,60,i);cPrice+=Point)
	  HourPrices[cPrice/Point]+=1;

Trouver des niveaux de résistance à partir d'un tel tableau n'est pas un problème. Ajoutez de nouvelles barres et supprimez les anciennes en même temps. Et la récupération de l'information se fait en deux cycles avec une seule condition ou ArrayMaximum donnera la valeur requise en une seule fois.

 
abolk:


Bien.

Il faut être tordu au point de transformer trois lignes de code claires en un code difficile à comprendre.

Si vous aviez eu l'idée de séparer le contrôle iLow, iHigh, vous auriez pu le faire tout de suite :

et ne pas toucher à quoi que ce soit

Une variante similaire à celle que j'ai suggérée plus haut (en séparant les "si").

Et vous n'avez même pas essayé de comprendre mon idée (bien que j'en aie brièvement décrit la logique)... Lorsque le prix est élevé, nous faisons un seul contrôle au lieu de deux. Il en va de même lorsque le prix est bas. Et lorsque le prix se situe dans les limites des barres historiques (ce qui est assez rare - c'est la logique et l'idée !), nous effectuons deux vérifications (il n'y a pas d'autre moyen).

Le chèque est pour le prix à l'extérieur du bar, pas à l'intérieur. Tout à l'heure, ils cherchaient une aiguille dans une botte de foin, tandis que moi, si je ne vois pas d'autre aiguille, je ne la chercherai pas non plus... L'aiguille se montrera quand elle sera nécessaire ! :)))

 
MaxZ:

Une variante similaire à celle que j'ai proposée ci-dessus (des "si" séparés).

Et vous n'avez même pas essayé de comprendre mon idée (bien que j'en aie brièvement décrit la logique)... Lorsque le prix est élevé, au lieu de deux chèques, nous en faisons un seul. Il en va de même lorsque le prix est bas. Et lorsque le prix se situe dans les limites des barres historiques (ce qui est assez rare - c'est la logique et l'idée !), nous effectuons deux vérifications (il n'y a pas d'autre moyen).

         if (LOWprice > iHigh(NULL,60,i)) continue;
        if (UPPprice < iLow (NULL,60,i)) continue;
Votre version peut être réduite à ces deux lignes ajoutées à la version de l'auteur, et avec quelques modifications des conditions devrait en principe être assez rapide.
1...162163164165166167168169170171172173174175176...652
Nouveau commentaire