"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> I really dont see the need for a FOR loop.  In the most general sense, FOR loops
> just increment from one value to another at a preset interval.  FOR loops are
> essentially just specialized WHILE loops and very easy to implement in POV
> without causing errors.

From a theoretical point of view you're perfectly right, but from a practical
point of view you're absolutely wrong.

The most common case of loop construct used in POV-Ray SDL is the standard
countng loop:

  #declare i = 1;
  #while (i <= 10000)
    //...
    #declare i = i + 1;
  #end

There is a lot of unnecessary typing involved here, and some of it is too easily
forgotten; as an aside, the loop construct, although perfectly documenting the
technical workings of the loop, doesn't make the programmer's original
intentions all too obvious, because it "atomizes" the whole loop into many
separate statements. The "#declare i = 1;" can easily get lost among other loop
initialization statements, and the "#declare i = i + 1;" can easily get lost
among the loop body. It's also quite inconsistent: Why would the start of the
range over which to loop be mentioned in a "#declare" statement, while only the
end of the range would be mentioned in the loop statement itself?

On the other hand, something like

  #for (i = 1 to 10000)
    //...
  #end

is much more concise, avoids unnecessary typing (no typing the loop variable 4
times and typing #declare twice, as in the #while version), shows better what's
going on here, is consistent in mentioning both start and end of the number
range in the loop statement itself, and - best of all - avoids the
all-too-common mistake of forgettig to increment.

If you think the #while loop is good enough, feel free to continue to use it,
but please - just because *you* don't need it, don't hinder others from getting
it. The current #while loop *is* a PITA for quite some folks, me included.


> FOR i = 1 to 6 STEP j
>   ...
> NEXT j
>
> #declare i=1; #while (i<=6)
>   ...
> #declare i=i+j; #end

Interestingly, you made all attempts to "compactify" the #while code, but not so
with the FOR code. How come?

Now give that loop variable a more verbose name, say CurrentIdx:

  #for (CurrentIdx = 1 to 6 step j)
    // ...
  #end

or

  #declare CurrentIdx = 1; #while (CurrentIdx <= 6)
    // ...
  #declare CurrentIdx = CurrentIdx + 1; #end

I know which version I'd prefer.

Also note that your version of trying to integrate the initialization and
increment into the loop itself leaves you with the "#while" and "#end" right in
the middle and the end of a line, respectively, making it difficult to visually
identify and match these statements quickly in the code.

> Most of the infinite loop situations that have been presented would not be
> solved properly with a FOR loop.  For example, any of the conditional increment
> type loops (counter is increased only if a certain condition is met) require
> extra steps in a FOR loop to work:

There's a difference here between statements that commonly create infinite
loops, and statements that an infinite-loop detector would have to be able to
properly cope with.

The loop that counts each and every iteration is *the* standard case, and also
*the* standard reason for undesired infinite loops. That's *the* classic use
case for a for-loop. If you want to count up only in certain cases, you're much
less likely to forget it - and it's also comparatively uncommon; for these
cases, #while-loops would continue to be the weapon of choice.

Post a reply to this message

> Now there is a problem in theoretical informatics known as the "halting
> problem": Given an arbitrary program and an arbitrary input, decide 
> whether the
> program will ultimately finish, or instead run forever. In 1936, Alan 
> Turing
> proved that for the general case of a Turing-complete engine, this halting
> problem is *not* decidable - in other words, for each and every 
> Turing-complete
> programming language it is *impossible* to come up with a generic 
> algorithm that
> can predict from any given program and any given starting conditions 
> whether it
> will enter an infinite loop or not.

I'm not saying it's possible to detect whether any program will stop or not. 
I'm saying that in *some* cases you can relatively easily detect that it 
won't stop without changing the functionality.

Post a reply to this message

>> Well rand() gives a different answer each time, so that can automatically 
>> be
>> counted as being reassigned in the eyes of the infinite-loop-catcher.  If
>> you try to implement your own RNG in a macro then obviously the random
>> variable will be reassigned so that would also count.
>
>  Which one of the myriad of variables inside a potential macro call should
> be enough change to decide that it's not an infinite loop?

"at least one of the variables mentioned in the #while condition"

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >> Well rand() gives a different answer each time, so that can automatically 
> >> be
> >> counted as being reassigned in the eyes of the infinite-loop-catcher.  If
> >> you try to implement your own RNG in a macro then obviously the random
> >> variable will be reassigned so that would also count.
> >
> >  Which one of the myriad of variables inside a potential macro call should
> > be enough change to decide that it's not an infinite loop?

> "at least one of the variables mentioned in the #while condition"

  What if there are no variables mentioned there?

-- 
                                                          - Warp

Post a reply to this message

>  What if there are no variables mentioned there?

It can just ignore it, the purpose is to catch a mistake like when you 
forget to increment the index counter, not catch all infinite loops (that is 
impossible).

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >  What if there are no variables mentioned there?

> It can just ignore it, the purpose is to catch a mistake like when you 
> forget to increment the index counter, not catch all infinite loops (that is 
> impossible).

  If the variable mentioned in the condition is not the variable which
changes and decides when the loop ends, the checker would give a false
positive.

-- 
                                                          - Warp

Post a reply to this message

>  If the variable mentioned in the condition is not the variable which
> changes and decides when the loop ends, the checker would give a false
> positive.

Can you give an example - I don't understand how that would work (I thought 
that the condition decided when the loop ended).

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >  If the variable mentioned in the condition is not the variable which
> > changes and decides when the loop ends, the checker would give a false
> > positive.

> Can you give an example - I don't understand how that would work (I thought 
> that the condition decided when the loop ended).

#declare Limit = .8;
#while(MyRand() < Limit)
  doSomething();
#end

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> scott <sco### [at] scottcom> wrote:
> > >  What if there are no variables mentioned there?
>
> > It can just ignore it, the purpose is to catch a mistake like when you
> > forget to increment the index counter, not catch all infinite loops (that is
> > impossible).
>
>   If the variable mentioned in the condition is not the variable which
> changes and decides when the loop ends, the checker would give a false
> positive.
>
> --
>                                                           - Warp

Perhaps the easiest and most universal solution to implement would be to add a
global "loop_limit" variable that would set the maximum number of loops allowed
(similar to max_trace value).  POV would then only need to keep track of the
number of iterations the current loop has gone through and kick it out when it
reaches the limit, rather than tracking any number of variables.  I would
expect that POV would also report an error (without aborting) to the message
window that a loop was terminated with the line number for debugging purposes.
To allow infinite loops as the current functionality is, one would set
loop_limit to 0 or -1.
The one disadvantage to this is that it would be globaL and apply to all loops
within the scene.

-tgq

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> > I really dont see the need for a FOR loop.  In the most general sense, FOR loops
> > just increment from one value to another at a preset interval.  FOR loops are
> > essentially just specialized WHILE loops and very easy to implement in POV
> > without causing errors.
>
> From a theoretical point of view you're perfectly right, but from a practical
> point of view you're absolutely wrong.
>
> The most common case of loop construct used in POV-Ray SDL is the standard
> countng loop:
>
>   #declare i = 1;
>   #while (i <= 10000)
>     //...
>     #declare i = i + 1;
>   #end
>
> There is a lot of unnecessary typing involved here, and some of it is too easily
> forgotten; as an aside, the loop construct, although perfectly documenting the
> technical workings of the loop, doesn't make the programmer's original
> intentions all too obvious, because it "atomizes" the whole loop into many
> separate statements. The "#declare i = 1;" can easily get lost among other loop
> initialization statements, and the "#declare i = i + 1;" can easily get lost
> among the loop body. It's also quite inconsistent: Why would the start of the
> range over which to loop be mentioned in a "#declare" statement, while only the
> end of the range would be mentioned in the loop statement itself?
>
> On the other hand, something like
>
>   #for (i = 1 to 10000)
>     //...
>   #end
>
> is much more concise, avoids unnecessary typing (no typing the loop variable 4
> times and typing #declare twice, as in the #while version), shows better what's
> going on here, is consistent in mentioning both start and end of the number
> range in the loop statement itself, and - best of all - avoids the
> all-too-common mistake of forgettig to increment.
>
> If you think the #while loop is good enough, feel free to continue to use it,
> but please - just because *you* don't need it, don't hinder others from getting
> it. The current #while loop *is* a PITA for quite some folks, me included.
>

I do agree that a for loop would be more concise and I'm not trying to hinder
you from getting it.  It was more a matter of showing that adding a #for
wouldn't add functionality that the current #while loop can't already do, it
just makes things more concise and recognizable, and perhaps easier to use (in
my earlier days I often wished I did have a for loop, however now, I just got
used to using the while loop).  If whatever programming overhead involved in
adding #for loop functionality is worth the value of having it, then, by all
means, it could/should be added.  The value being in simpler coding rather than
added functionality.

>
> > FOR i = 1 to 6 STEP j
> >   ...
> > NEXT j
> >
> > #declare i=1; #while (i<=6)
> >   ...
> > #declare i=i+j; #end
>
> Interestingly, you made all attempts to "compactify" the #while code, but not so
> with the FOR code. How come?
>
> Now give that loop variable a more verbose name, say CurrentIdx:
>
>   #for (CurrentIdx = 1 to 6 step j)
>     // ...
>   #end
>
> or
>
>   #declare CurrentIdx = 1; #while (CurrentIdx <= 6)
>     // ...
>   #declare CurrentIdx = CurrentIdx + 1; #end
>
> I know which version I'd prefer.
>
> Also note that your version of trying to integrate the initialization and
> increment into the loop itself leaves you with the "#while" and "#end" right in
> the middle and the end of a line, respectively, making it difficult to visually
> identify and match these statements quickly in the code.
>


Compactifying it wasn't intended to sell one over the other.  It was merely to
demonstrate how the #while works as a #for.  Combining the lines as shown is
how I write my for-type loops currently to make them recognizable as for loops
and also to not lose the initial value and step function in the code.


> > Most of the infinite loop situations that have been presented would not be
> > solved properly with a FOR loop.  For example, any of the conditional increment
> > type loops (counter is increased only if a certain condition is met) require
> > extra steps in a FOR loop to work:
>
> There's a difference here between statements that commonly create infinite
> loops, and statements that an infinite-loop detector would have to be able to
> properly cope with.
>
> The loop that counts each and every iteration is *the* standard case, and also
> *the* standard reason for undesired infinite loops. That's *the* classic use
> case for a for-loop. If you want to count up only in certain cases, you're much
> less likely to forget it - and it's also comparatively uncommon; for these
> cases, #while-loops would continue to be the weapon of choice.

Agreed somewhat.  Because of the way I present my for loops, I usually don't
encounter an infinite loop problem.  This is where careful coding helps.  In
this case it is a visible coding error that can easily be corrected when
identified.

The area I usually encounter inifinite loops is with conditional while loops.
In this case, the error is not noticeable and often not avoidable through
careful programming.  A lot of debuggin and variable tracking/watching is often
needed to figure out why the conditional statement isn't triggering.

An example is placing non-intersecting spheres in a box.  If the maximum count
is greater than what can actually fit in the volume (i.e., the loop reaches a
point where it can no longer find a big enough space to place a new sphere, but
keeps trying because the max number of objects hasn't been reached), an inifnite
loop will be encountered.  This only a simple demonstration as, in reality, it
should be obvious what is causing the inifinite loop once it is located,
however, the presence of the inifinite loop would not (likely) be obvious by
simple examination of the written code (i.e. it is not a coding error).

-tgq

Post a reply to this message