"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