Ungewöhnliches Verhalten des WHILE-Operators - Seite 2

[lord_hiro]

Das macht keinen Unterschied, denke ich. Ich könnte auch schreiben IF( StringHighStatus == "True" || SwingHighShift > SwingBarcount ) EndCycle = TRUE;

Der Punkt ist, warum das IF die Exit-Bedingung erkennt und dann das WHILE auf die bool-Variable reagiert, während es nicht endet, wenn ich die gleiche Bedingung in das WHILE einfüge?

[Tjipke de Vries]

lord_hiro:

Das macht keinen Unterschied, denke ich. Ich könnte auch schreiben IF( StringHighStatus == "True" || SwingHighShift > SwingBarcount ) EndCycle = TRUE;

Der Punkt ist, warum das IF die Exit-Bedingung erkennt und dann das WHILE auf die bool-Variable reagiert, während es nicht endet, wenn ich die gleiche Bedingung in das WHILE einfüge?

Sieht für mich so aus

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

als

while (!EndCycle)
   {
   
  ...
      if( StringHighStatus == "True" ) EndCycle = TRUE;
      if( SwingHighShift > SwingBarCount ) EndCycle = TRUE;
   }

[Syed Naufal Gaddafi]

Ja, manchmal führt die Umkehrung der Logik zu dem, was wir erreichen wollen.

[lord_hiro]

deVries, vielleicht liege ich falsch, aber ich denke, dass eine Folge von IF den Booleschen Wert auf TRUE setzt, wie es ein logisches OR tut.

Wenn die erste Bedingung erfüllt ist, wird EndCycle TRUE, wenn die zweite nicht erfüllt ist, bleibt es TRUE.

Umgekehrt wird es TRUE, wenn die erste Bedingung nicht erfüllt ist, die zweite aber schon.

Zu diesem Zeitpunkt erkennt das WHILE die Exit-Bedingung.

Zwei IFs in Folge verhalten sich also wie ein logisches OR und dasselbe gilt für eine IF...ELSE IF-Sequenz.

Und es muss ein ODER sein, es kann kein UND sein, sonst kann das WHILE stecken bleiben (die Bedingung auf der Zeichenkette kann unendlich oft falsch sein).

Warum verwaltet das WHILE eine einzelne boolesche Variable, deren Wert innerhalb des Zyklus gesetzt wird, während es das Ergebnis der gleichen logischen ODER-Operation innerhalb seiner Bedingungsdefinition nicht bestimmen kann?

Dieser EA wurde in der Vergangenheit von vielen Leuten benutzt, vor Build 600 und auch vor 500, und dies ist die letzte Version. Keiner hat sich beschwert.

Meine Frage lautet also: Gibt es jemanden, der nach Build 600 Probleme mit dem WHILE-Operator hat?

[James Hodges]

Die Antwort ist ja...., aber vielleicht hat es nichts mit dem Aufbau und viel mit der Codierung zu tun....LOL

[Syed Naufal Gaddafi]

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

Haben Sie schon einmal versucht, eine sehr einfache logische Operation durchzuführen, nur um zu sehen, ob sie funktioniert oder nicht, anstatt zu fragen?

[Keith Watford]

lord_hiro:

deVries, vielleicht liege ich falsch, aber ich denke, dass eine Folge von IF den Booleschen Wert auf TRUE setzt, wie es ein logisches OR tut.

Wenn die erste Bedingung erfüllt ist, wird EndCycle TRUE, wenn die zweite nicht erfüllt ist, bleibt es TRUE.

Umgekehrt wird es TRUE, wenn die erste Bedingung nicht erfüllt ist, die zweite aber schon.

Zu diesem Zeitpunkt erkennt das WHILE die Exit-Bedingung.

Zwei IFs in Folge verhalten sich also wie ein logisches OR und dasselbe gilt für eine IF...ELSE IF-Sequenz.

Und es muss ein ODER sein, es kann kein UND sein, sonst kann das WHILE stecken bleiben (die Bedingung auf der Zeichenkette kann unendlich oft falsch sein).

Warum verwaltet das WHILE eine einzelne boolesche Variable, deren Wert innerhalb des Zyklus gesetzt wird, während es das Ergebnis der gleichen logischen ODER-Operation innerhalb seiner Bedingungsdefinition nicht bestimmen kann?

Dieser EA wurde in der Vergangenheit von vielen Leuten benutzt, vor Build 600 und auch vor 500, und dies ist die letzte Version. Keiner hat sich beschwert.

Meine Frage lautet also: Gibt es jemanden, der nach Build 600 Probleme mit dem WHILE-Operator hat?

Ich denke, dass Sie sich auf Folgendes beziehen

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

Ihr Code, wenn er genau so wäre, wie Sie ihn gepostet haben, hätte mit keinem Build das gemacht, was Sie erwarten, also müssen Sie etwas geändert haben

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

     }

[lord_hiro]

deysmacro:
Haben Sie jemals versucht, eine sehr grundlegende , während Logik Operationen nur zu bestätigen, es funktioniert wie es sollte oder nicht, anstatt zu fragen?

Mein Beitrag begann mit einem Beispiel für ein WHILE, das mir ein ungewöhnliches Verhalten zu zeigen schien, das dem des Teils des EA, über den wir jetzt diskutieren, sehr ähnlich war, also habe ich erst probiert und dann gefragt.

Meine Interpretation dieser sehr einfachen Fehlersuche erwies sich als falsch, sodass sich die Diskussion auf den EA selbst verlagerte.

[lord_hiro]

Danke GumRai für deine Geduld.

Vielleicht liege ich falsch und habe einen Dickschädel, aber ich kann die Logik nicht verstehen...

Wenn das erste IF, wie du vorschlägst, die Zeichenkette auf "true" setzt, z.B. bei SwinghHighShift=10, dann steigt der Zähler in diesem Zyklus nicht an; danach kehrt die Steuerung zum WHILE zurück: der Zyklus sollte an diesem Punkt enden, weil das WHILE ein logisches OR enthält und eine seiner Bedingungen erfüllt ist.

Umgekehrt, wenn die Variable falsch bleibt, sollte der Zähler seinen Maximalwert erreichen und Sie haben wieder die Exit-Bedingung.

Ich denke, dass Ihre Überlegung auch mit einem AND-Operator zutreffen würde.

Ihrer Interpretation folgend könnte ich das ODER innerhalb des WHILE weglassen; ich könnte einfach die erste WENN-Bedingung auf die Zeichenkette anwenden: wenn sie "wahr" wird, dann wird der Break das WHILE beenden, andernfalls würde der Zähler weiterlaufen bis zu seinem Maximum.

Der Code wird dann zu:

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

     }

Aber das ist immer noch ein Workaround und erklärt (für mich) leider nicht, warum das WHILE sich nicht um das OR kümmert.

[Keith Watford]

lord_hiro:

Wenn das erste IF, wie Sie vorschlagen, die Zeichenkette auf "true" setzt, z. B. bei SwinghHighShift=10, dann wird der Zähler in diesem Zyklus nicht erhöht; danach kehrt die Steuerung zum WHILE zurück: Der Zyklus sollte an diesem Punkt enden, weil das WHILE ein logisches ODER enthält und eine seiner Bedingungen erfüllt ist.

Ja, eine der while-Bedingungen ist erfüllt, aber der Code wird in diesem Fall nicht beendet, sondern geht zum for weiter und befindet sich in einer Endlosschleife.