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

Post a reply to this message

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

As I already wrote to clipka when he mentioned the rand() function, as the 
result could be different each time from a macro, the infinite-loop-checker 
effectively would assume that the result was being reassigned each loop, so 
not flag it up as an infinite loop.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > #declare Limit = .8;
> > #while(MyRand() < Limit)
> >  doSomething();
> > #end

> As I already wrote to clipka when he mentioned the rand() function, as the 
> result could be different each time from a macro, the infinite-loop-checker 
> effectively would assume that the result was being reassigned each loop, so 
> not flag it up as an infinite loop.

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

-- 
                                                          - Warp

Post a reply to this message

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