Warp <war### [at] tagpovrayorg> wrote:
> Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> > 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).
>
>   Or to add a #for loop construct.
>
>   (I have thrown some suggestions to the team about this.)
>
> --
>                                                           - Warp

Adding the #for loop only solves the problem with a misplaced or missing
increment statement, which is purely a programmer's error that can be largely
avoided with a little diligence by the programmer.  Of course this is the type
of infinite loop scenerio that the OP is referring to.

This will not solve other infinite loop problems that are not related to
programmer error such as conditional statements that are never satisfied due to
some issue that is not superficially apparent.

The #for loop would add some ease and conciseness to the coding end and help
users avoid this programming error, but it would not add any functionality
overall that isn't already achievable through a properly constructed #while
loop.

I am not arguing that there is no need for a #for loop.  As long as it can be
easily instituted and not become more fluff in the machine, I am all *for* it,
and would likely even use it.

Beyond that, I do think now that a loop_limiter variable as I have described may
have some usage in the SDL.  It can help abort and identify existing *infinite*
(or rather, high-count, potentially infinite) loops within the code that are
not apparent to the user in many situations.  It may also be of direct intended
usage where the user wants to force loops to terminate after a maximum number of
iterations for whatever reason (this can be done through coding, but it would be
an added benefit of having the global variable).


One further item on the potential creation of #for loops:  Would they be best
end-bracketted with the general #end statement (as #while, #if, #switch and
#macro all use)? Or would it be more appropriate to add a "#next" statement or
even "#next n" statement instead?  #end would make it more consistent with
current programming practice, but #next would make the #for loop construct more
visible and identifiable.  Along this line of thinking, perhaps more specific
#end statements would also be more appropriate for the other situations as
well: #while/#wend, #if/#endif, #switch/(#send?), #macro/(#mend?).  Of course
you would likely keep the #end functionality for backwards compatibility.



-tgq

Post a reply to this message

"scott" <sco### [at] scottcom> wrote:
> 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.

I'm definitely repeating myself here: Those easy cases would come packaged with
too many not-so-easy special cases.

Sure you can detect a simple

  #while (i < N)
    //#declare i=...
  #end

as being an infinite loop, but that's an absolutely trivial case; as soon as you
go from there to

  #while (i < N)
    ...
    //#declare i=...
    ...
  #end

then if you don't find a "#declare i=...", you *must* examine the "..."
thoroughly before you can conclude that the user really forgot it.

Of course, if you *do* find a "#declare i=..." in there, you can tell for sure
the user did *not* forget it; but that doesn't get us any further.

The bottom line is that a potentially-infite-loop detector would be a quite
complex piece of code, even if it were just to catch some standard cases. There
would be much easier and more useful remedies for the forgotten-increment
ailment.

Post a reply to this message

Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> One further item on the potential creation of #for loops:  Would they be best
> end-bracketted with the general #end statement (as #while, #if, #switch and
> #macro all use)? Or would it be more appropriate to add a "#next" statement or
> even "#next n" statement instead?  #end would make it more consistent with
> current programming practice, but #next would make the #for loop construct more
> visible and identifiable.

  I don't support the idea of adding new keywords just to serve as comments.
If you want to comment your code, use comments. I personally use this style
quite a lot:

#while(a < b)
  some stuff here

  #while(c < d)
    some other stuff here

    #if(something)
      more stuff here
    #end // #if(something)

    additional stuff

  #end // #while(c < d)
#end // #while(a < b)

  (In fact, I use this style with large blocks when programming in C++ as
well.)

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> > One further item on the potential creation of #for loops:  Would they be best
> > end-bracketted with the general #end statement (as #while, #if, #switch and
> > #macro all use)? Or would it be more appropriate to add a "#next" statement or
> > even "#next n" statement instead?  #end would make it more consistent with
> > current programming practice, but #next would make the #for loop construct more
> > visible and identifiable.
>
>   I don't support the idea of adding new keywords just to serve as comments.
> If you want to comment your code, use comments. I personally use this style
> quite a lot:
>
> #while(a < b)
>   some stuff here
>
>   #while(c < d)
>     some other stuff here
>
>     #if(something)
>       more stuff here
>     #end // #if(something)
>
>     additional stuff
>
>   #end // #while(c < d)
> #end // #while(a < b)
>
>   (In fact, I use this style with large blocks when programming in C++ as
> well.)
>
> --
>                                                           - Warp

I wasn't necessarily arguing for the addition of the keywords, just commenting
on whether a #for loop should be consistent with the other constructs and end
with #end.  If it was felt that they should have their own #next keyword, then
the extension of that argument would be that all the other constructs should as
well.

I will admit that having a bunch of nested #end statements can become confusing
figuring out which belongs to any of the constructs present without good
commenting and/or scoping.  However, adding the commenting does require extra
typing and lessens the conciseness of the construct which is one of the
arguments in favour of adding #for.

One thing you can't do at present would be something along the lines of:

#declare i=0;
#while (i<5)
  ...
  #if (something happens that makes me want to terminate the loop early)
    #declare i=-1;
    #end
  #else
    #declare i=i+1;
  #end
#end

as the #end statements get confused.  Granted this is not good programming
protocol and is achievable by other methods, it is merely a demonstration of a
conceivable issue.  Construct-specific end statements could allow for this
(however, leaving #end for backwards compatibility would preclude allowing this
anyways).

All in all, I would support the continued usage of #end for all constructs as
well as for a new #for construct.

-tgq

Post a reply to this message

Trevor G Quayle <Tin### [at] hotmailcom> wrote:
> #declare i=0;
> #while (i<5)
>   ...
>   #if (something happens that makes me want to terminate the loop early)
>     #declare i=-1;
>     #end
>   #else
>     #declare i=i+1;
>   #end
> #end

  I think that what you wanted to express there is a #break, not an #end.
(No, #break does not currently interrupt loops, although I don't see any
reason why it couldn't.)

  You can currently achieve the same effect with:

#declare i=0;
#while (i<5)
  ...
  #if (something happens that makes me want to terminate the loop early)
    #declare i=5;
  #else
    #declare i=i+1;
  #end
#end

-- 
                                                          - Warp

Post a reply to this message

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

That sounds like an option.

I'm not sure though whether it would be superior to just waiting for the user to
decide that it was about time for the parsing to finish.


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

I disagree. Just dropping out of a loop before all conditions have been
established that might be presumed by the following code may mess up, and in
some cases (software using #write) actually have the potential to mess up data.


Maybe just printing a debug info but continuing with the loop would be the most
sensible thing to do; if the user finds that it doesn't make sense to keep the
loop going, he can abort the render anytime.


> The one disadvantage to this is that it would be globaL and apply to all loops
> within the scene.

I don't see a problem with that. Of couse you could specify a max iteration
thing per loop, but then again that would be quite redundant in the cases it's
most needed.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> > 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.
>
> That sounds like an option.
>
> I'm not sure though whether it would be superior to just waiting for the user to
> decide that it was about time for the parsing to finish.
>

It would give the user the advantage of pointing out the offending loop.

>
> > 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.
>
> I disagree. Just dropping out of a loop before all conditions have been
> established that might be presumed by the following code may mess up, and in
> some cases (software using #write) actually have the potential to mess up data.
>
>
> Maybe just printing a debug info but continuing with the loop would be the most
> sensible thing to do; if the user finds that it doesn't make sense to keep the
> loop going, he can abort the render anytime.
>

This is true assuming that the user does not want an infinite loop situation at
all.

There are circumstances where the user may want the loop to continue until it
reaches an assumed infinite loop and then jump the loop and get on with the
render.
For example, the non-intersecting spheres in a box scenerio I described before.
The user may want as many spheres as possible to fit in the box, but does not
really know the practical limit.  (I know this scenario could be handled with a
large for loop or by other means, but it is meant as a simple demonstration of
an intended situation)


>
> > The one disadvantage to this is that it would be globaL and apply to all loops
> > within the scene.
>
> I don't see a problem with that. Of couse you could specify a max iteration
> thing per loop, but then again that would be quite redundant in the cases it's
> most needed.

I agree it wouldn't likely be a problem in most circumstances.

-tgq

Post a reply to this message

"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

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> Adding the #for loop only solves the problem with a misplaced or missing
> increment statement, which is purely a programmer's error that can be largely
> avoided with a little diligence by the programmer.  Of course this is the type
> of infinite loop scenerio that the OP is referring to.
>
> This will not solve other infinite loop problems that are not related to
> programmer error such as conditional statements that are never satisfied due to
> some issue that is not superficially apparent.

Those, to, by definition are programmer errors, BTW.


> The #for loop would add some ease and conciseness to the coding end and help
> users avoid this programming error, but it would not add any functionality
> overall that isn't already achievable through a properly constructed #while
> loop.

*No* loop does. #while() is perfectly able to save it all, when properly
combined with #if() constructs.

Like with #for loops, the corresponding #while replacement may become
cumbersome, but it's perfectly possible.


> One further item on the potential creation of #for loops:  Would they be best
> end-bracketted with the general #end statement (as #while, #if, #switch and
> #macro all use)? Or would it be more appropriate to add a "#next" statement or
> even "#next n" statement instead?  #end would make it more consistent with
> current programming practice, but #next would make the #for loop construct more
> visible and identifiable.

Whith all other statements bracketed with #end, for consistency's sake there's
virtually no other way as to close them with #end, too. And why not?

Sure, a "#next i" statement helps identify the "#for" statement it belongs to,
but then again you can achieve the same through good indentation, or using
"#end // i".


> Along this line of thinking, perhaps more specific
> #end statements would also be more appropriate for the other situations as
> well: #while/#wend, #if/#endif, #switch/(#send?), #macro/(#mend?).  Of course
> you would likely keep the #end functionality for backwards compatibility.

I'd personally favor completely different bracketing rules anyways, using {}
instead (to use the same bracketing rules as for object statements, and
functions for that matter). Though I know various people (I don't dare make any
estimate here) would disagree.

I don't think a #wend, #send, #mend etc. is really necessary, and #endif would
make this inconsistent anyway.

If at all (there is a bit of a point here to identify the type of statement that
you expect to be ending, so as to enable the parser to better pin down where you
goofed the #end matching), I'd rather go for "#end if", "#end macro" etc.

Post a reply to this message

>  How can the checker know that the result is different each time the macro
> is called?

It doesn't, it just assumes it is to avoid a false positive situation.

Post a reply to this message