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

Post a reply to this message

"bgimeno" <bgimeno[at]persistencia[dot]org> wrote:
> #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

You're not the first one to do this :)


> I suppose that a "detector" of infinite loops is it too much to ask?

What should be the detection criterion?

I want a proper for-loop anyway.

Post a reply to this message

bgimeno <bgimeno[at]persistencia[dot]org> wrote:
> I suppose that a "detector" of infinite loops is it too much to ask?

  It is, in fact. How do you detect an infinite loop? That's especially
difficult given that it has been mathematically proven to be an impossible
task in the general case.

  You could put an enforced upper limit to any loop, but how large would
that upper limit be? What if you really need to go over that limit? Also
an upper limit is not of much help if the body of the loop takes a very
long time to parse anyways: The upper limit would not be triggered anytime
soon.

-- 
                                                          - Warp

Post a reply to this message

"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