Comportamento strano dell'operatore WHILE - pagina 2

Nuovo commento
 

Questo non fa alcuna differenza, credo. Potrei anche scrivere IF( StringHighStatus == "True" || SwingHighShift > SwingBarcount ) EndCycle = TRUE;

Il punto è perché l'IF rileva la condizione di uscita e poi il WHILE reagisce alla variabile bool mentre se metto la stessa condizione dentro il WHILE non finisce?

 
lord_hiro:

Questo non fa alcuna differenza, credo. Potrei anche scrivere IF( StringHighStatus == "True" || SwingHighShift > SwingBarcount ) EndCycle = TRUE;

Il punto è perché l'IF rileva la condizione di uscita e poi il WHILE reagisce alla variabile bool mentre se metto la stessa condizione dentro il WHILE non finisce?


Mi sembra che questo funzioni

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

come

while (!EndCycle)
   {
   
  ...
      if( StringHighStatus == "True" ) EndCycle = TRUE;
      if( SwingHighShift > SwingBarCount ) EndCycle = TRUE;
   }
 
Sì, a volte invertendo la logica si ottiene quello che vogliamo ottenere.
 

deVries, forse mi sbaglio ma penso che una sequenza di IF trasformi il booleano in VERO come fa un OR logico.

Se la prima condizione corrisponde allora EndCycle diventa TRUE, se la seconda non lo fa allora rimane TRUE.

Viceversa, se la prima non è soddisfatta ma la seconda sì, allora diventa VERO.

A questo punto il WHILE riconosce la condizione di uscita.

Quindi due IF in sequenza si comportano come un OR logico e lo stesso fa una sequenza IF...ELSE IF.

E deve essere un OR, non può essere un AND altrimenti il WHILE può bloccarsi (la condizione sulla stringa può essere falsa all'infinito).

Perché il WHILE gestisce una singola variabile booleana il cui valore è impostato all'interno del ciclo mentre non può determinare il risultato della stessa operazione logica OR all'interno della sua definizione di condizione?

Questo EA è stato usato da molte persone in passato, prima della build 600 e anche prima della 500, e questa è l'ultima release. Nessuno si è lamentato.

Quindi la mia domanda è: c'è qualcuno che ha problemi con l'operatore WHILE dopo la build 600?

 
La risposta è sì.... tuttavia potrebbe non avere nulla a che fare con la costruzione e molto a che fare con la codifica....LOL
  
So my question is: is there anyone experiencing troubles with the WHILE operator after build 600?
Avete mai provato un'operazione logica molto elementare, solo per confermare che sta funzionando come dovrebbe o no, invece di chiedere?
 
lord_hiro:

deVries, forse mi sbaglio ma penso che una sequenza di IF trasformi il booleano in VERO come fa un OR logico.

Se la prima condizione corrisponde allora EndCycle diventa TRUE, se la seconda non lo fa allora rimane TRUE.

Viceversa, se la prima non è soddisfatta ma la seconda sì, allora diventa VERO.

A questo punto il WHILE riconosce la condizione di uscita.

Quindi due IF in sequenza si comportano come un OR logico e lo stesso fa una sequenza IF...ELSE IF.

E deve essere un OR, non può essere un AND altrimenti il WHILE può bloccarsi (la condizione sulla stringa può essere falsa all'infinito).

Perché il WHILE gestisce una singola variabile booleana il cui valore è impostato all'interno del ciclo mentre non può determinare il risultato della stessa operazione logica OR all'interno della sua definizione di condizione?

Questo EA è stato usato da molte persone in passato, prima della build 600 e anche prima della 500, e questa è l'ultima release. Nessuno si è lamentato.

Quindi la mia domanda è: c'è qualcuno che ha problemi con l'operatore WHILE dopo la build 600?

Penso che tu ti stia riferendo a questo

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

Il tuo codice, se esattamente come hai postato non avrebbe fatto come ti aspetti con qualsiasi build, quindi devi aver cambiato qualcosa

   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:
Hai mai provato un'operazione logica molto elementare con un while solo per confermare che sta funzionando come dovrebbe o no, invece di chiedere?


Il mio post è iniziato con un esempio di un WHILE che mi sembrava restituire un comportamento insolito molto simile a quello del pezzo di EA di cui stiamo discutendo ora, così ho prima provato poi chiesto.

La mia interpretazione di quel debug molto semplice si è rivelata sbagliata, quindi la discussione si è spostata sull'EA stesso.

 

Grazie GumRai per la tua pazienza.

Forse mi sbaglio e ho la testa dura ma non riesco a capire la logica...

Se il primo IF trasforma, come suggerisci tu, la stringa in "true" a diciamo SwinghHighShift=10 allora il contatore non aumenta in quel ciclo; dopo di che il controllo torna al WHILE: il ciclo dovrebbe finire a questo punto perché il WHILE contiene un OR logico e una delle sue condizioni è soddisfatta.

Al contrario, se la variabile rimane falsa, il contatore dovrebbe raggiungere il suo valore massimo e di nuovo si ha la condizione di uscita.

Penso che la tua considerazione sarebbe vera con un operatore AND.

Seguendo la tua interpretazione potrei saltare l'OR all'interno del WHILE; potrei semplicemente mettere la prima condizione IF sulla stringa: se diventa "vero" allora il break terminerà il WHILE, altrimenti il contatore andrebbe avanti fino al suo massimo.

Il codice si trasformerà in:

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

     }

Ma questo è ancora un workaround e, purtroppo, non spiega (a me) perché il WHILE non si occupa dell'OR.

 
lord_hiro:


Se il primo IF trasforma, come suggerisci tu, la stringa in "true" a diciamo SwinghHighShift=10 allora il conteggio non aumenta in quel ciclo; dopo di che il controllo torna al WHILE: il ciclo dovrebbe finire a questo punto perché il WHILE contiene un OR logico e una delle sue condizioni è soddisfatta.

Sì, una delle condizioni del while è soddisfatta, ma il codice non esce in questo caso, passa al for ed è in un ciclo infinito.
1234
Nuovo commento
Motivazione: