Comportamento estranho do operador WHILE - página 2

Novo comentário
 

Isso não faz diferença, eu acho. Eu também poderia escrever IF( StringHighStatus == "True" || SwingHighShift > SwingBarcount ) EndCycle = TRUE;

A questão é porque o IF detecta a condição de saída e então o WHILE reage à variável bool enquanto que se eu colocar a mesma condição dentro do WHILE ela não termina?

 
lord_hiro:

Isso não faz diferença, acho eu. Eu também poderia escrever IF( StringHighStatus == "True" || SwingHighShift > SwingBarcount ) EndCycle = TRUE;

A questão é porque o IF detecta a condição de saída e então o WHILE reage à variável bool enquanto que se eu colocar a mesma condição dentro do WHILE ela não termina?


Parece-me que isto funciona

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

como

while (!EndCycle)
   {
   
  ...
      if( StringHighStatus == "True" ) EndCycle = TRUE;
      if( SwingHighShift > SwingBarCount ) EndCycle = TRUE;
   }
 
Sim, às vezes, reverter a lógica conseguiria o que queremos alcançar.
 

deVries, talvez eu esteja errado, mas eu acho que uma seqüência de IF transforma o booleano em VERDADEIRO como um OR lógico.

Se a primeira condição corresponder, então EndCycle se transforma em VERDADEIRO, se a segunda não corresponder, então ela permanece VERDADEIRA.

Viceversa se a primeira não for cumprida, mas a segunda for, então ela se torna VERDADEIRA.

Neste momento, o WHILE reconhece a condição de saída.

Portanto, dois IFs em seqüência se comportam como um OR lógico e o mesmo faz um IF...ELSE IF em seqüência.

E deve ser um OR, não pode ser um AND, caso contrário o WHILE pode ficar preso (a condição na corda pode ser falsa indefinidamente).

Por que o QUEM administra uma única variável booleana cujo valor é definido dentro do ciclo enquanto não pode determinar o resultado da mesma operação lógica OU dentro da definição de sua condição?

Esta EA já foi usada por muitas pessoas no passado, antes de construir 600 e também antes de 500, e este é o último lançamento. Ninguém reclamou.

Então minha pergunta é: há alguém que tenha problemas com o operador WHILE depois de construir 600?

 
A resposta é sim...., porém pode não ter nada a ver com a construção e muito a ver com a codificação....LOL
  
So my question is: is there anyone experiencing troubles with the WHILE operator after build 600?
Você já tentou uma operação lógica muito básica apenas para confirmar que está funcionando como deveria ou não, em vez de perguntar?
 
lord_hiro:

deVries, talvez eu esteja errado, mas eu acho que uma seqüência de IF transforma o booleano em VERDADEIRO como um OR lógico.

Se a primeira condição corresponder, então EndCycle se transforma em VERDADEIRO, se a segunda não corresponder, então ela permanece VERDADEIRA.

Viceversa se a primeira não for cumprida, mas a segunda for, então ela se torna VERDADEIRA.

Neste momento, o WHILE reconhece a condição de saída.

Portanto, dois IFs em seqüência se comportam como um OR lógico e o mesmo faz um IF...ELSE IF em seqüência.

E deve ser um OR, não pode ser um AND, caso contrário o WHILE pode ficar preso (a condição na corda pode ser falsa indefinidamente).

Por que o QUEM administra uma única variável booleana cujo valor é definido dentro do ciclo enquanto não pode determinar o resultado da mesma operação lógica OU dentro da definição de sua condição?

Esta EA já foi usada por muitas pessoas no passado, antes de construir 600 e também antes de 500, e este é o último lançamento. Ninguém reclamou.

Então minha pergunta é: há alguém que tenha problemas com o operador WHILE depois de construir 600?

Eu acho que você está se referindo a isto

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

Seu código, se exatamente como você postou, não teria feito como você esperava com qualquer construção, então você deve ter mudado 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:
Você já tentou uma operação lógica muito básica apenas para confirmar que está funcionando como deveria ou não, em vez de perguntar?


Meu posto começou com um exemplo de um WHILE que me pareceu retornar um comportamento muito similar ao da parte da EA que estamos discutindo agora, então eu primeiro tentei então perguntar.

Minha interpretação dessa depuração muito simples acabou sendo errada, então a discussão passou para a própria EA.

 

Obrigado GumRai por sua paciência.

Talvez eu esteja errado e de cabeça dura, mas não consigo entender a lógica...

Se o primeiro IF vira, como você sugere, o fio para "verdadeiro" a dizer SwinghHighShift=10, então a contagem não aumenta nesse ciclo; depois disso, o controle volta para o QUANTO: o ciclo deve terminar neste ponto porque o QUANTO contém um OU lógico e uma de suas condições é satisfeita.

Por outro lado, se a variável permanecer falsa, o contador deve atingir seu valor máximo e novamente você tem a condição de saída.

Acho que sua consideração seria verdadeira com um operador AND.

Seguindo sua interpretação, eu poderia pular o OU dentro do OU; eu poderia apenas colocar a primeira condição IF na corda: se se tornar "verdadeira", então a quebra terminará o OU, caso contrário o contador continuará até seu máximo.

O código se voltará para:

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

     }

Mas isto ainda é uma alternativa e, infelizmente, não explica (para mim) porque o QUEM não cuida do OR.

 
lord_hiro:


Se o primeiro IF vira, como você sugere, o fio para "verdadeiro" em SwinghHighShift=10, então a contagem não aumenta nesse ciclo; depois disso, o controle volta ao WHILE: o ciclo deve terminar neste ponto porque o WHILE contém um OU lógico e uma de suas condições é satisfeita.

Sim, uma das condições do tempo está satisfeita, mas o código não sai neste caso, ele passa para o for e está em um loop infinito.
1234
Novo comentário