Comportement étrange de l'opérateur WHILE - page 2

Nouveau commentaire
 

Cela ne fait aucune différence, je pense. Je pourrais aussi écrire IF( StringHighStatus == "True" || SwingHighShift > SwingBarcount ) EndCycle = TRUE ;

La question est de savoir pourquoi l'IF détecte la condition de sortie et ensuite le WHILE réagit à la variable bool alors que si je place la même condition dans le WHILE, il ne se termine pas ?

 
lord_hiro:

Cela ne fait aucune différence, je pense. Je pourrais aussi écrire IF( StringHighStatus == "True" || SwingHighShift > SwingBarcount ) EndCycle = TRUE ;

La question est de savoir pourquoi l'IF détecte la condition de sortie et ensuite le WHILE réagit à la variable bool alors que si je place la même condition dans le WHILE, il ne se termine pas ?


Il me semble que cela fonctionne

while (StringHighStatus == "False" &&  SwingHighShift <= SwingBarCount)

comme

while (!EndCycle)
   {
   
  ...
      if( StringHighStatus == "True" ) EndCycle = TRUE;
      if( SwingHighShift > SwingBarCount ) EndCycle = TRUE;
   }
 
Oui, parfois, inverser la logique permet d'obtenir ce que l'on veut.
 

deVries, je me trompe peut-être mais je pense qu'une séquence d'IF transforme le booléen en VRAI comme le fait un OR logique.

Si la première condition est remplie, EndCycle devient VRAI, si la seconde ne l'est pas, il reste VRAI.

À l'inverse, si la première condition n'est pas remplie mais que la seconde l'est, elle devient VRAIE.

À ce moment-là, le WHILE reconnaît la condition de sortie.

Ainsi, deux IF en séquence se comportent comme un OR logique et il en va de même pour une séquence IF...ELSE IF.

Et ce doit être un OU, ce ne peut pas être un ET sinon le WHILE peut rester bloqué (la condition sur la chaîne peut être fausse indéfiniment).

Pourquoi le WHILE gère-t-il une seule variable booléenne dont la valeur est fixée à l'intérieur du cycle alors qu'il ne peut pas déterminer le résultat de la même opération logique OU à l'intérieur de sa définition de condition ?

Cette EA a été utilisée par beaucoup de personnes dans le passé, avant la build 600 et aussi avant la 500, et c'est la dernière version. Personne ne s'est plaint.

Ma question est donc la suivante : quelqu'un a-t-il rencontré des problèmes avec l'opérateur WHILE après la version 600 ?

 
La réponse est oui.... mais cela n'a peut-être rien à voir avec la construction et beaucoup à voir avec le codage....LOL.
  
So my question is: is there anyone experiencing troubles with the WHILE operator after build 600?
Avez-vous déjà essayé d'effectuer des opérations logiques de base, juste pour confirmer qu'elles fonctionnent comme elles le devraient ou non, au lieu de les demander ?
 
lord_hiro:

deVries, je me trompe peut-être mais je pense qu'une séquence d'IF transforme le booléen en VRAI comme le fait un OR logique.

Si la première condition est remplie, EndCycle devient VRAI, si la seconde ne l'est pas, il reste VRAI.

À l'inverse, si la première condition n'est pas remplie mais que la seconde l'est, elle devient VRAIE.

À ce moment-là, le WHILE reconnaît la condition de sortie.

Ainsi, deux IF en séquence se comportent comme un OR logique et il en va de même pour une séquence IF...ELSE IF.

Et ce doit être un OU, ce ne peut pas être un ET sinon le WHILE peut rester bloqué (la condition sur la chaîne peut être fausse indéfiniment).

Pourquoi le WHILE gère-t-il une seule variable booléenne dont la valeur est fixée à l'intérieur du cycle alors qu'il ne peut pas déterminer le résultat de la même opération logique OU à l'intérieur de sa définition de condition ?

Cette EA a été utilisée par beaucoup de personnes dans le passé, avant la build 600 et aussi avant la 500, et c'est la dernière version. Personne ne s'est plaint.

Ma question est donc la suivante : quelqu'un a-t-il rencontré des problèmes avec l'opérateur WHILE après la version 600 ?

Je pense que vous faites référence à ceci

while (StringHighStatus == "False" || SwingHighShift <= SwingBarCount)

Votre code, s'il était exactement comme vous l'avez posté, n'aurait pas fonctionné comme prévu avec n'importe quelle version, vous avez donc dû modifier quelque chose.

   while(StringHighStatus=="False" || SwingHighShift<=SwingBarCount)
     {

      if(iFractals(NULL,0,MODE_UPPER,SwingHighShift)==iHigh(NULL,0,SwingHighShift) && iFractals(NULL,0,MODE_UPPER,SwingHighShift)>Close[0])
        {
         //IF THIS CONDITION IS TRUE AT, FOR EXAMPLE SwingHighShift=10
         StringHighStatus="True";
         SwingHigh=SwingHighShift;
         ObjectDelete("SwingHigh");
         ObjectCreate("SwingHigh",OBJ_VLINE,0,Time[SwingHigh],0);
         ObjectSet("SwingHigh",OBJPROP_COLOR,Red);
         //THEN StringHighStatus="True" BUT SwingHighShift IS NOT INCREASED IN THIS BLOCK OF CODE
         //SO WHEN CONTROL IS HANDED BACK TO THE WHILE OPERATOR, SwingHighShift WILL REMAIN UNCHANGED AT 10
         //SO THIS BLOCK OF CODE WILL BE REPEATED OVER AND OVER CHECKING BAR SHIFT 10, BECAUSE THERE IS NO WAY OUT!
         //HOW TO RESOLVE? SIMPLY USE         
         break;
        }
      else
        {
         SwingHighShift++;
        }

     }
 
deysmacro:
Avez-vous déjà essayé d'effectuer des opérations logiques très simples, juste pour confirmer qu'elles fonctionnent comme elles le devraient ou non, au lieu de demander ?


Mon message commençait par un exemple de WHILE qui me semblait renvoyer un comportement inhabituel très similaire à celui de la partie de l'EA dont nous discutons maintenant, j'ai donc d'abord essayé puis demandé.

Mon interprétation de ce débogage très simple s'est avérée erronée et la discussion s'est déplacée vers l'EA elle-même.

 

Merci GumRai pour votre patience.

Peut-être que je me trompe et que j'ai la tête dure mais je n'arrive pas à comprendre la logique...

Si le premier IF transforme, comme vous le suggérez, la chaîne de caractères en "true" à disons SwinghHighShift=10 alors le compteur n'augmente pas dans ce cycle ; après cela le contrôle revient au WHILE : le cycle devrait se terminer à ce point car le WHILE contient un OR logique et une de ses conditions est satisfaite.

Inversement, si la variable reste fausse, le compteur devrait atteindre sa valeur maximale et vous avez à nouveau la condition de sortie.

Je pense que votre considération serait vraie avec un opérateur AND.

En suivant votre interprétation, je pourrais sauter l'opérateur OR à l'intérieur du WHILE ; je pourrais simplement mettre la première condition IF sur la chaîne de caractères : si elle devient "true", le break mettra fin au WHILE, sinon le compteur continuera jusqu'à sa valeur maximale.

Le code se transformera en :

   while(SwingHighShift<=SwingBarCount)
     {

      if(iFractals(NULL,0,MODE_UPPER,SwingHighShift)==iHigh(NULL,0,SwingHighShift) && iFractals(NULL,0,MODE_UPPER,SwingHighShift)>Close[0])
        {
         
         StringHighStatus="True";
         SwingHigh=SwingHighShift;
         ObjectDelete("SwingHigh");
         ObjectCreate("SwingHigh",OBJ_VLINE,0,Time[SwingHigh],0);
         ObjectSet("SwingHigh",OBJPROP_COLOR,Red);
        
         break;
        }
      else
        {
         SwingHighShift++;
        }

     }

Mais cela reste une solution de rechange et, malheureusement, cela n'explique pas (pour moi) pourquoi le WHILE ne s'occupe pas du OU.

 
lord_hiro:


Si le premier IF transforme, comme vous le suggérez, la chaîne de caractères en "true" à, disons, SwinghHighShift=10, alors le comptage n'augmente pas dans ce cycle ; après cela, la commande revient au WHILE : le cycle devrait se terminer à ce moment-là parce que le WHILE contient un OU logique et qu'une de ses conditions est satisfaite.

Oui, l'une des conditions du while est satisfaite, mais le code ne sort pas dans ce cas, il passe au for et se trouve dans une boucle sans fin.
1234
Nouveau commentaire