Odd behaviour of WHILE operator - page 2

New comment
 

That makes no difference, I think. I could also write IF( StringHighStatus == "True" || SwingHighShift > SwingBarcount ) EndCycle = TRUE;

The point is why the IF detects the exit condition and then the WHILE reacts to the bool variable whilst if I put the same condition inside the WHILE it doesn't end?

 
lord_hiro:

That makes no difference, I think. I could also write IF( StringHighStatus == "True" || SwingHighShift > SwingBarcount ) EndCycle = TRUE;

The point is why the IF detects the exit condition and then the WHILE reacts to the bool variable whilst if I put the same condition inside the WHILE it doesn't end?


Looks to me this works

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

as

while (!EndCycle)
   {
   
  ...
      if( StringHighStatus == "True" ) EndCycle = TRUE;
      if( SwingHighShift > SwingBarCount ) EndCycle = TRUE;
   }
 
Yes, sometimes reversing the logic would get what we want to achieve.
 

deVries, maybe I'm wrong but I think that a sequence of IF turns the boolean to TRUE as a logical OR does.

If the first condition matches then EndCycle turns to TRUE, if the second one doesn't then it remains TRUE.

Viceversa if the first is not met but the second one is, then it becomes TRUE.

At this time the WHILE recognizes the exit condition.

So two IFs in sequence behave like a logical OR and the same does an IF...ELSE IF sequence.

And it must be an OR, it can't be an AND otherwise the WHILE can stuck (the condition on the string can be false indefinitely).

Why the WHILE manages a single boolean variable whose value is set inside the cycle whilst it can't determine the result of the same logical OR operation inside his condition definition?

This EA has been used by a lot of people in the past, before build 600 and also before 500, and this is the last release. No one complained.

So my question is: is there anyone experiencing troubles with the WHILE operator after build 600?

 
The answer is yes.... however it may have nothing to do with the build and much to do with the coding....LOL
  
So my question is: is there anyone experiencing troubles with the WHILE operator after build 600?
Have you ever tried a very basic while logic operations just to confirm it is working like it should or not, instead of asking?
 
lord_hiro:

deVries, maybe I'm wrong but I think that a sequence of IF turns the boolean to TRUE as a logical OR does.

If the first condition matches then EndCycle turns to TRUE, if the second one doesn't then it remains TRUE.

Viceversa if the first is not met but the second one is, then it becomes TRUE.

At this time the WHILE recognizes the exit condition.

So two IFs in sequence behave like a logical OR and the same does an IF...ELSE IF sequence.

And it must be an OR, it can't be an AND otherwise the WHILE can stuck (the condition on the string can be false indefinitely).

Why the WHILE manages a single boolean variable whose value is set inside the cycle whilst it can't determine the result of the same logical OR operation inside his condition definition?

This EA has been used by a lot of people in the past, before build 600 and also before 500, and this is the last release. No one complained.

So my question is: is there anyone experiencing troubles with the WHILE operator after build 600?

I think that you are referring to this

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

Your code, if exactly as you posted would have not done as you expect with any build, so you must have changed something

   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:
Have you ever tried a very basic while logic operations just to confirm it is working like it should or not, instead of asking?


My post started with an example of a WHILE that seemed to me to return an unusual behaviour very similar to that of the chunk of EA we are discussing now, so I first tried then asked.

My interpretation of that very simple debugging turned out to be wrong so the discussion moved to the EA itself.

 

Thank you GumRai for your patience.

Maybe I'm wrong and hard headed but I can't understand the logic...

If the first IF turns, as you suggest, the string to "true" at say SwinghHighShift=10 then the counted doesn't increase in that cycle; after that the control gets back to the WHILE: the cycle should end at this point because the WHILE contains a logical OR and one of it's condition is satisfied.

Conversely if the variable stays false the counter should reach its maximum value and again you have the exit condition.

I think your consideration would be true with an AND operator.

Following your interpretation I could skip the OR inside the WHILE; I could just put the first IF condition on the string: if turns to "true" then the break will end the WHILE, otherwise the counter would go on on till its maximum.

The code will turn to:

   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++;
        }

     }

But this is still a workaround and, sadly, it does not explain (to me) why the WHILE doesn't take care of the OR.

 
lord_hiro:


If the first IF turns, as you suggest, the string to "true" at say SwinghHighShift=10 then the counted doesn't increase in that cycle; after that the control gets back to the WHILE: the cycle should end at this point because the WHILE contains a logical OR and one of it's condition is satisfied.

Yes, one of the while's conditions is satisfied, but the code doesn't exit in this case, it moves on to the for and is in an endless loop.
1234
New comment