"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> 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.

Ah, so then it seems we're actually of the same opinion.

The fact that from a functionality point of view, a #while() loop is perfectly
fit to be used instead of a #for loop (or any other possible loop for that
matter) is not much news to me though - and given how it's introduced in the
POV-Ray manual I'd be surprised if it was news to any significant number of
people, so I naturally assumed you were doubting its added value.


> 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).

Okay, that's a different point though. Note however that this is a perfect
example for where code analysis would come to its limits identifying the
endless loop; after all, it's not an issue of code structure but a geometrical
one, and you cannot come up with an algorithm to solve every possible such
decision. Even worse, what if there would theoretically be just enough space
for another such a sphere, but the random number generator happens to never
ever produce the respective position with the given seed?

So in this case it's up to the developer to think of a suitable upper bound when
to terminate the loop, and design it right into it:

  #declare SpheresPlaced = 0;
  #declare i = 0; #while ((Spheres < MaxSpheres) & (i < MaxLoops))
    ...
    #if (Whatever)
      ...
      #declare Spheres = Spheres + 1;
      // maybe also #declare i = 0;
    #end
    ...
  #declare i = i + 1; #end

Something like this. I don't think there's much that will save you from putting
this kind of thought into a non-straightforward counting loop.


I guess an interesting syntax for such constructs would be something like this:

  #for Spheres = 1 to 10000
    ...
    #if (Whatever)
      ...
    #else
      #retry 10 // new keyword, in addition to the #for keyword
    #end
  #end

which would be to say, if the condition does not hold true, abort the current
iteration and re-iterate without incrementing the counter - unless you tried 10
times in a row without success already, in which case abort the loop.

Post a reply to this message