"bgimeno" <bgimeno[at]persistencia[dot]org> wrote:
> I don't know if there is a special case in which a loop of  the variable
> "FooCounter" should remain unchanged.
> But what about a simple detector where the value of "FooCounter" from the
> #while(FooCounter cond) condition does not change when you reach the end of
> the loop?.

First of all, this would require special handling for conditional expressions to
detect the presence of such a construct during parsing.

Furthermore, consider this:

  #declare R = seed(4711);
  #declare Items = 0;
  #while (Items < 10000)
    #declare MyPos = SomeRandomPosition(R);
    #if (SomeCondition(MyPos))
      DoSomething(MyPos)
      #declare Items = Items + 1;
    #end
  #end

Obviously, the problem is more complicated than just checking whether the
variable value actually changes in each loop: Runtime checking won't do, you'd
need code analysis. Also note that the increment may be hidden nested deeply in
macros, so this is not a straightforward check for the existence of a "#declare
FooCounter = ..." somewhere inside the loop.

In my eyes it would be a kludge anyway, so why not heal the leg instead, and add
a proper #for loop - I'm sure we'd have that issue solved then.

(If POV 4 does indeed get a new SDL as promised, I'm quite sure it will not come
without a for loop anyway.)

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> Impossible to catch all infinite loops, but the parser could check to make 
> sure at least one of the variables mentioned in the #while condition is 
> reassigned within the loop.  That would catch a lot of mistakes (eg 
> forgetting to increment the index variable).

  What if it's not incremented within the loop? Maybe it's incremented
elsewhere (eg. inside a macro called from the loop).

-- 
                                                          - Warp

Post a reply to this message

"scott" <sco### [at] scottcom> wrote:
> Impossible to catch all infinite loops, but the parser could check to make
> sure at least one of the variables mentioned in the #while condition is
> reassigned within the loop.  That would catch a lot of mistakes (eg
> forgetting to increment the index variable).

What if we're talking about a loop like this:

  #declare abortProb = 0.03;
  #while(rand(R) > abortProb)
    //...
  #end

Still insist on the variable being re-assigned? What if not rand() is used, but
some macro creating a non-uniform distribution?

What if no variable is used at all, as in:

  #while(rand(R) > 0.03)
    //...
  #end


I do know I keep repeating myself, but: Why on earth try to come up with
ever-so-complex ways to detect a broken counting #while loop without breaking
other uses of the #while statement, when really the root problem is the absence
of a proper #for loop?

Virtually no-one is asking for an infinite loop detection in other languages
like Pascal, C, VB or what-have-you. Why? Because they do have a for-loop so
you usually don't encounter this blunder there.

Post a reply to this message

>  What if it's not incremented within the loop? Maybe it's incremented
> elsewhere (eg. inside a macro called from the loop).

Does the parser re-parse a macro each time it is called?

Post a reply to this message

> What if we're talking about a loop like this:
>
>  #declare abortProb = 0.03;
>  #while(rand(R) > abortProb)
>    //...
>  #end

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.

> I do know I keep repeating myself, but: Why on earth try to come up with
> ever-so-complex ways to detect a broken counting #while loop without 
> breaking
> other uses of the #while statement, when really the root problem is the 
> absence
> of a proper #for loop?

Agreed.  Although I still think you could detect some common infinite loop 
situations without breaking any existing behaviour.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "scott" <sco### [at] scottcom> wrote:
> I do know I keep repeating myself, but: Why on earth try to come up with
> ever-so-complex ways to detect a broken counting #while loop without breaking
> other uses of the #while statement, when really the root problem is the absence
> of a proper #for loop?
>
> Virtually no-one is asking for an infinite loop detection in other languages
> like Pascal, C, VB or what-have-you. Why? Because they do have a for-loop so
> you usually don't encounter this blunder there.


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.

FOR i = 1 to 6 STEP j
  ...
NEXT j

#declare i=1; #while (i<=6)
  ...
#declare i=i+j; #end

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:

#declare i=1; #while (i<6)
  ...
  #if(condition)
    #declare i=i+j;
  #end
#end


FOR i = 1 to 6 STEP j
  ...
  IF (NOT condition)
    i=i-j
  ENDIF
NEXT j


I don't think that there are any 'infinite loop' detectors that would be of
universal value to add to POV.  I little bit of diligence and debugging on the
part of the user can easily overcome any issue.  In the past, whenever I have
put together a #while loop that isn't working properly, setting up value
reporting with the #debug statement usually was able to show if a value wasn't
progressing as expected and help pinpoint the problem.

-tgq

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >  What if it's not incremented within the loop? Maybe it's incremented
> > elsewhere (eg. inside a macro called from the loop).

> Does the parser re-parse a macro each time it is called?

  Currently yes.

-- 
                                                          - Warp

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> > What if we're talking about a loop like this:
> >
> >  #declare abortProb = 0.03;
> >  #while(rand(R) > abortProb)
> >    //...
> >  #end

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

-- 
                                                          - Warp

Post a reply to this message

"scott" <sco### [at] scottcom> wrote:
> >  What if it's not incremented within the loop? Maybe it's incremented
> > elsewhere (eg. inside a macro called from the loop).
>
> Does the parser re-parse a macro each time it is called?

Yes - at least the POV 3.x parser does. Chances are a POV 4 parser will not.

Post a reply to this message

"scott" <sco### [at] scottcom> wrote:
> Agreed.  Although I still think you could detect some common infinite loop
> situations without breaking any existing behaviour.

The problem here, and the point some of us are trying to make, is that those
"common infinite loop situations" would be riddled with "uncommon finite loop
situation" exceptions, which all would have to be tested for in order to not
break anything.

As for an exhaustive test, it is absolutely *impossible* to do:

POV-Ray's SDL is "Turing-complete", a term from theoretical informatics roughly
eqivalent to saying, "you can use it to write *any* program you can ever
imagine" (leaving aside memory and performance constraints, that is).

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.

It is possible to restrict a computer language in such a way as to force the
halting problem to be decideable for that engine, but only at the cost of no
longer being Turing-complete, i.e. reduction of *some* functionality.

Post a reply to this message