>  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

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


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

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

Post a reply to this message

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

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.

Post a reply to this message

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

"at least one of the variables mentioned in the #while condition"

Post a reply to this message