Comportamiento extraño del operador WHILE - página 2

Nuevo comentario
 

Eso no hace ninguna diferencia, creo. También podría escribir IF( StringHighStatus == "True" || SwingHighShift > SwingBarcount ) EndCycle = TRUE;

La cuestión es por qué el IF detecta la condición de salida y luego el WHILE reacciona a la variable bool mientras que si pongo la misma condición dentro del WHILE no termina?

 
lord_hiro:

Eso no hace ninguna diferencia, creo. También podría escribir IF( StringHighStatus == "True" || SwingHighShift > SwingBarcount ) EndCycle = TRUE;

La cuestión es por qué el IF detecta la condición de salida y luego el WHILE reacciona a la variable bool mientras que si pongo la misma condición dentro del WHILE no termina?


Me parece que esto funciona

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

como

while (!EndCycle)
   {
   
  ...
      if( StringHighStatus == "True" ) EndCycle = TRUE;
      if( SwingHighShift > SwingBarCount ) EndCycle = TRUE;
   }
 
Sí, a veces invirtiendo la lógica conseguiríamos lo que queremos lograr.
 

deVries, tal vez me equivoque pero creo que una secuencia de IF convierte el booleano en TRUE como lo hace un OR lógico.

Si la primera condición coincide entonces EndCycle se convierte en TRUE, si la segunda no lo hace entonces sigue siendo TRUE.

Viceversa si la primera no se cumple pero la segunda sí, entonces se convierte en TRUE.

En este momento el WHILE reconoce la condición de salida.

Así que dos IFs en secuencia se comportan como un OR lógico y lo mismo hace una secuencia IF...ELSE IF.

Y debe ser un OR, no puede ser un AND de lo contrario el WHILE puede atascarse (la condición en la cadena puede ser falsa indefinidamente).

¿Por qué el WHILE maneja una sola variable booleana cuyo valor se establece dentro del ciclo mientras que no puede determinar el resultado de la misma operación lógica OR dentro de su definición de condición?

Este EA ha sido utilizado por mucha gente en el pasado, antes de la build 600 y también antes de la 500, y esta es la última versión. Nadie se ha quejado.

Así que mi pregunta es: ¿hay alguien que tenga problemas con el operador WHILE después de la versión 600?

 
La respuesta es sí.... sin embargo puede que no tenga nada que ver con la construcción y sí con la codificación....LOL
  
So my question is: is there anyone experiencing troubles with the WHILE operator after build 600?
¿Has probado alguna vez a realizar operaciones lógicas muy básicas para confirmar que funciona como debería o no, en lugar de preguntar?
 
lord_hiro:

deVries, tal vez me equivoque pero creo que una secuencia de IF convierte el booleano en TRUE como lo hace un OR lógico.

Si la primera condición coincide entonces EndCycle se convierte en TRUE, si la segunda no lo hace entonces sigue siendo TRUE.

Viceversa si la primera no se cumple pero la segunda sí, entonces se convierte en TRUE.

En este momento el WHILE reconoce la condición de salida.

Así que dos IFs en secuencia se comportan como un OR lógico y lo mismo hace una secuencia IF...ELSE IF.

Y debe ser un OR, no puede ser un AND de lo contrario el WHILE puede atascarse (la condición en la cadena puede ser falsa indefinidamente).

¿Por qué el WHILE maneja una sola variable booleana cuyo valor se establece dentro del ciclo mientras que no puede determinar el resultado de la misma operación lógica OR dentro de su definición de condición?

Este EA ha sido utilizado por mucha gente en el pasado, antes de la build 600 y también antes de la 500, y esta es la última versión. Nadie se ha quejado.

Así que mi pregunta es: ¿hay alguien que tenga problemas con el operador WHILE después de la versión 600?

Creo que te refieres a esto

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

Tu código, si es exactamente como lo has publicado, no habría hecho lo que esperas con cualquier build, así que debes haber cambiado algo

   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:
¿Has probado alguna vez una operación muy básica de lógica while sólo para confirmar que funciona como debería o no, en lugar de preguntar?


Mi post comenzó con un ejemplo de un WHILE que me pareció que devolvía un comportamiento inusual muy similar al del trozo de EA que estamos discutiendo ahora, así que primero probé y luego pregunté.

Mi interpretación de esa depuración tan sencilla resultó ser errónea, así que la discusión se trasladó al propio EA.

 

Gracias GumRai por tu paciencia.

Tal vez esté equivocado y sea un cabeza dura pero no consigo entender la lógica...

Si el primer IF convierte, como sugieres, la cadena en "true" en digamos SwinghHighShift=10 entonces el contador no aumenta en ese ciclo; después de eso el control vuelve al WHILE: el ciclo debería terminar en este punto porque el WHILE contiene un OR lógico y una de sus condiciones se satisface.

A la inversa, si la variable se mantiene falsa el contador debería alcanzar su valor máximo y de nuevo tienes la condición de salida.

Creo que tu consideración sería cierta con un operador AND.

Siguiendo tu interpretación podría omitir el OR dentro del WHILE; podría simplemente poner la primera condición IF en la cadena: si se convierte en "true" entonces el break terminará el WHILE, de lo contrario el contador seguiría hasta su máximo.

El código se convertirá 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++;
        }

     }

Pero esto sigue siendo una solución y, lamentablemente, no explica (para mí) por qué el WHILE no se encarga del OR.

 
lord_hiro:


Si el primer IF convierte, como sugieres, la cadena en "true" en digamos SwinghHighShift=10 entonces el conteo no se incrementa en ese ciclo; después de eso el control vuelve al WHILE: el ciclo debería terminar en este punto porque el WHILE contiene un OR lógico y una de sus condiciones se satisface.

Sí, una de las condiciones del while se satisface, pero el código no sale en este caso, pasa al for y está en un bucle sin fin.
1234
Nuevo comentario