"bgimeno" <bgimeno[at]persistencia[dot]org> wrote:
> The following code is perfectly valid to the present version, but does not
> produce anything.
>
> #declare FooCount = 0 ;
> #while (FooCount < 100 )
> sphere {<0,FooCount,0>,1 pigment { rgb< 1, 1, 0> } }
> // #declare FooCount = FooCount + 1 ; // note this missing line
> #end
>
> I suppose that a "detector" of infinite loops is it too much to ask?
>
> B. Gimeno

When I write a counting loop, I tend to do it as follows:

#declare FooCount = 0 ; #while (FooCount < 100 )
   > BLAH BLAH BLAH
#declare FooCount = FooCount + 1 ; #end

I know there are circumstances where this can't be done, but I find it helps me
recognize my "for" type loops easily.

-tgq

Post a reply to this message

I don't know if there is a special case in which a loop of  the variable 
"FooCounter" should remain unchanged.
But what about a simple detector where the value of "FooCounter" from the 
#while(FooCounter cond) condition does not change when you reach the end of 
the loop?.

If this is an "insurmountable" logical hole guess we will have to settle for 
what is, but thanks anyway for your reply.

B. Gimeno

Post a reply to this message

bgimeno <bgimeno[at]persistencia[dot]org> wrote:
> I don't know if there is a special case in which a loop of  the variable 
> "FooCounter" should remain unchanged.
> But what about a simple detector where the value of "FooCounter" from the 
> #while(FooCounter cond) condition does not change when you reach the end of 
> the loop?.

  Just because it didn't change in one loop doesn't mean it will never
change.

-- 
                                                          - Warp

Post a reply to this message

"bgimeno" <bgimeno[at]persistencia[dot]org> wrote:
> I don't know if there is a special case in which a loop of  the variable
> "FooCounter" should remain unchanged.
> But what about a simple detector where the value of "FooCounter" from the
> #while(FooCounter cond) condition does not change when you reach the end of
> the loop?.
>
> If this is an "insurmountable" logical hole guess we will have to settle for
> what is, but thanks anyway for your reply.
>
> B. Gimeno

Actually, I just wrote some code that has that.  The loop counter is
conditionally incremented, and the condition isn't known until after it is
evaluated.  I cut out some earlier code that wasn't relevant (mostly file
writing stuff).

#local i = 0;
#local seaweedCount = 10000;

#while( i < seaweedCount )
    #local xcord = xdist * rand(rs1) + bounds1.x;
    #local zcord = zdist * rand(rs1) + bounds1.z;

    #local normVect = <0,0,0>;
    #local intersectVect = trace(o_rocks,<xcord,10,zcord>, <0.5,-1,1>,
normVect);

    #if( intersectVect.y < waterLevel + 0.5 )
        sphere
        {
            intersectVect, 0.05
            texture{ marker1s }
        }
        #local i = i + 1;

    #end
#end

Basically it selects a random point within the bounds of a heightfield, then
uses trace to find the exact point on the heightfield.  It then checks to make
sure the point is close to the water level.  If the point isn't slightly above
the water level or lower, the counter is not incremented.  In this way I get
seaweedCount (10000) objects where I need them, and not 10000 total attempts to
place an object, whether it is successful or not.

It is quite possible to place a secondary condition so that it "bails out" after
some very high number of tries, but only the individual user can decide for a
given instance of where and what that condition should be.

-Reactor

Post a reply to this message

It's not really an infinite loop condition detector but a "I forgot to increment
my variable"-detector:

Check if the loop condition variable is being reassigned inside the loop.

Post a reply to this message

Aydan <hes### [at] hendrik-sachsenet> wrote:
> Check if the loop condition variable is being reassigned inside the loop.

  Impossible in the general case.

  Besides, you are assuming that there is a single unambiguous "loop condition
variable". The condition in the #while construct can be *anything*. It can be
a complex expression, it can be a function or macro call, it can contain a
condition composed of many variables...

  For example, if you had something like this:

#while(xCoord * 2.5 < yCoord * 5 & sqrt(zCoord) < 10 * zSize)

how would POV-Ray check that this isn't an infinite loop?

-- 
                                                          - Warp

Post a reply to this message

>> Check if the loop condition variable is being reassigned inside the loop.
>
>  Impossible in the general case.
>
>  Besides, you are assuming that there is a single unambiguous "loop 
> condition
> variable". The condition in the #while construct can be *anything*. It can 
> be
> a complex expression, it can be a function or macro call, it can contain a
> condition composed of many variables...
>
>  For example, if you had something like this:
>
> #while(xCoord * 2.5 < yCoord * 5 & sqrt(zCoord) < 10 * zSize)
>
> how would POV-Ray check that this isn't an infinite loop?

Impossible to catch all infinite loops, but the parser could check to make 
sure at least one of the variables mentioned in the #while condition is 
reassigned within the loop.  That would catch a lot of mistakes (eg 
forgetting to increment the index variable).

Post a reply to this message

"bgimeno" <bgimeno[at]persistencia[dot]org> wrote:
> I don't know if there is a special case in which a loop of  the variable
> "FooCounter" should remain unchanged.
> But what about a simple detector where the value of "FooCounter" from the
> #while(FooCounter cond) condition does not change when you reach the end of
> the loop?.

First of all, this would require special handling for conditional expressions to
detect the presence of such a construct during parsing.

Furthermore, consider this:

  #declare R = seed(4711);
  #declare Items = 0;
  #while (Items < 10000)
    #declare MyPos = SomeRandomPosition(R);
    #if (SomeCondition(MyPos))
      DoSomething(MyPos)
      #declare Items = Items + 1;
    #end
  #end

Obviously, the problem is more complicated than just checking whether the
variable value actually changes in each loop: Runtime checking won't do, you'd
need code analysis. Also note that the increment may be hidden nested deeply in
macros, so this is not a straightforward check for the existence of a "#declare
FooCounter = ..." somewhere inside the loop.

In my eyes it would be a kludge anyway, so why not heal the leg instead, and add
a proper #for loop - I'm sure we'd have that issue solved then.

(If POV 4 does indeed get a new SDL as promised, I'm quite sure it will not come
without a for loop anyway.)

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> Impossible to catch all infinite loops, but the parser could check to make 
> sure at least one of the variables mentioned in the #while condition is 
> reassigned within the loop.  That would catch a lot of mistakes (eg 
> forgetting to increment the index variable).

  What if it's not incremented within the loop? Maybe it's incremented
elsewhere (eg. inside a macro called from the loop).

-- 
                                                          - Warp

Post a reply to this message

"scott" <sco### [at] scottcom> wrote:
> Impossible to catch all infinite loops, but the parser could check to make
> sure at least one of the variables mentioned in the #while condition is
> reassigned within the loop.  That would catch a lot of mistakes (eg
> forgetting to increment the index variable).

What if we're talking about a loop like this:

  #declare abortProb = 0.03;
  #while(rand(R) > abortProb)
    //...
  #end

Still insist on the variable being re-assigned? What if not rand() is used, but
some macro creating a non-uniform distribution?

What if no variable is used at all, as in:

  #while(rand(R) > 0.03)
    //...
  #end


I do know I keep repeating myself, but: Why on earth try to come up with
ever-so-complex ways to detect a broken counting #while loop without breaking
other uses of the #while statement, when really the root problem is the absence
of a proper #for loop?

Virtually no-one is asking for an infinite loop detection in other languages
like Pascal, C, VB or what-have-you. Why? Because they do have a for-loop so
you usually don't encounter this blunder there.

Post a reply to this message