checking a loop execution

checking a loop execution

[pumilia]

Is there a way to check if a loop has been exited before completion or
if all iterations have been performed?
In fortran the loop index is increased one last time, at the end of
the loop, but in Ada that trick cannot be exploited; the index is not
even defined outside the loop.
I could add a control variable (ivar, in my example) to take care of the
iteration number when exiting, but that would decrease the peformance
of my algorithm

Example

procedure loop_test  is

ivar : integer;

begin
 for i in 1 .. 10 loop
 if <condition>  then
  ivar := i;
  exit ;
 end if ;
 end loop;
 put(ivar,2);
end loop_test;



thank you for your suggestions

Pol


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: checking a loop execution

[DuckE]

First: Your example will result in an undefined value for ivar if
<condition> is never met.

Second: I sometimes use the construct:

  procedure loop_test is
  begin
    for i in 1 .. 10 loop
      if <condition> then
        put( i, 2 );
        return;
      end if;
    end loop;
    put( defaultValue, 2 ); -- default value when condition is never met
  end loop_test;

  I don't know if it's more or less efficient, but it does eliminate the
extra variable.

  BTW: I usually avoid having more than one exit point from a procedure, but
in
  a routine this small I think it actually reads better.

  SteveD

<pumilia@my-deja.com> wrote in message news:8dl76u$etf$1@nnrp1.deja.com...
> Is there a way to check if a loop has been exited before completion or
> if all iterations have been performed?
> In fortran the loop index is increased one last time, at the end of
> the loop, but in Ada that trick cannot be exploited; the index is not
> even defined outside the loop.
> I could add a control variable (ivar, in my example) to take care of the
> iteration number when exiting, but that would decrease the peformance
> of my algorithm
>
> Example
>
> procedure loop_test  is
>
> ivar : integer;
>
> begin
>  for i in 1 .. 10 loop
>  if <condition>  then
>   ivar := i;
>   exit ;
>  end if ;
>  end loop;
>  put(ivar,2);
> end loop_test;
>
>
>
> thank you for your suggestions
>
> Pol
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Re: checking a loop execution

[chad]

The following code does what you want:

  declare
      Index      : Integer := 1;
      Interupted : Boolean := False;
  begin

      loop

          Interupted := <Condition>;

          exit when  Interupted or else (Index = 10);

          Index      := Index + 1;

      end loop;

      if Interupted then
          Put_Line("Loop interupted at :" & Integer'Image(Index));
      else
          Put_Line("Loop was not interupted.");
      end if;

end;

Although the above code seems a little verboes, I feel that it makes the
logic clearer.

<pumilia@my-deja.com> wrote in message news:8dl76u$etf$1@nnrp1.deja.com...
> Is there a way to check if a loop has been exited before completion or
> if all iterations have been performed?
> In fortran the loop index is increased one last time, at the end of
> the loop, but in Ada that trick cannot be exploited; the index is not
> even defined outside the loop.
> I could add a control variable (ivar, in my example) to take care of the
> iteration number when exiting, but that would decrease the peformance
> of my algorithm
>
> Example
>
> procedure loop_test  is
>
> ivar : integer;
>
> begin
>  for i in 1 .. 10 loop
>  if <condition>  then
>   ivar := i;
>   exit ;
>  end if ;
>  end loop;
>  put(ivar,2);
> end loop_test;
>
>
>
> thank you for your suggestions
>
> Pol
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

Re: checking a loop execution

[Robert Dewar]

In article <38fece05.0@silver.truman.edu>,
  "chad" <crmeiners@hotmail.com> wrote:
> The following code does what you want:
>
>   declare
>       Index      : Integer := 1;
>       Interupted : Boolean := False;
>   begin
>
>       loop
>
>           Interupted := <Condition>;

I find the use of boolean variables like this annoying
obfuscation in many cases. I would not mind at all using
a goto for this special case of a loop with multiple exits.
Some languages have a special construct for this, but if
this is lacking, then really the goto is as clear as anything
and avoids duplicating a test.

Yes, I know some people get the heebie-jeebies when they
see a goto, but just remember you weren't born this way,
it is learned behavior, and it can be unlearned. Almost
every style rule should be considered as a guide, and the
really skilled programmer is one who does not have to rely
on absolute rules like "Never use a goto", and instead knows
enough to discriminate.

Code like

for J in 1.. 10 loop
   if Condition then goto Loop_Interrupted;
   ....
end loop;

--  Here if loop ends normally

...
return;

--  Here if loop ends abnormally

<<Loop_Interrupted>>
...
return;


reads quite clearly to me, and I would be surprised and a
bit puzzled by any programmer to whom it did NOT read
clearly.

And as someone pointed out, if the interrupted section is
short, you can simply put it right in the loop (of course
a return from the middle of a scope is also a goto, but
often an acceptable one -- the amusing thing is people who
hate *all* gotos, but don't recognize that statements like
return are gotos :-)

I think I mentioned before running into a COBOL programmer
who hated gotos but had no hesitation in writing a STOP RUN
verb deeply embedded into his program :-)

Sometimes I have seen goto allergic people do this in Ada
too, interfacing the exit routine!




Sent via Deja.com http://www.deja.com/
Before you buy.

Re: checking a loop execution

[Robert Dewar]

In article <38fece05.0@silver.truman.edu>,
  "chad" <crmeiners@hotmail.com> wrote:
> The following code does what you want:
>
>   declare
>       Index      : Integer := 1;
>       Interupted : Boolean := False;
>   begin
>
>       loop
>
>           Interupted := <Condition>;

I find the use of boolean variables like this annoying
obfuscation in many cases. I would not mind at all using
a goto for this special case of a loop with multiple exits.
Some languages have a special construct for this, but if
this is lacking, then really the goto is as clear as anything
and avoids duplicating a test.

Yes, I know some people get the heebie-jeebies when they
see a goto, but just remember you weren't born this way,
it is learned behavior, and it can be unlearned. Almost
every style rule should be considered as a guide, and the
really skilled programmer is one who does not have to rely
on absolute rules like "Never use a goto", and instead knows
enough to discriminate.

Code like

for J in 1.. 10 loop
   if Condition then goto Loop_Interrupted;
   ....
end loop;

--  Here if loop ends normally

...
return;

--  Here if loop ends abnormally

<<Loop_Interrupted>>
...
return;


reads quite clearly to me, and I would be surprised and a
bit puzzled by any programmer to whom it did NOT read
clearly.

And as someone pointed out, if the interrupted section is
short, you can simply put it right in the loop (of course
a return from the middle of a scope is also a goto, but
often an acceptable one -- the amusing thing is people who
hate *all* gotos, but don't recognize that statements like
return are gotos :-)

I think I mentioned before running into a COBOL programmer
who hated gotos but had no hesitation in writing a STOP RUN
verb deeply embedded into his program :-)

Sometimes I have seen goto allergic people do this in Ada
too, interfacing the exit routine!




Sent via Deja.com http://www.deja.com/
Before you buy.

Re: checking a loop execution

[Chad R. Meiners]

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:8do7b2$p8h$1@nnrp1.deja.com...
> In article <38fece05.0@silver.truman.edu>,
>   "chad" <crmeiners@hotmail.com> wrote:
> > The following code does what you want:
> >
> >   declare
> >       Index      : Integer := 1;
> >       Interupted : Boolean := False;
> >   begin
> >
> >       loop
> >
> >           Interupted := <Condition>;
>
> I find the use of boolean variables like this annoying
> obfuscation in many cases. I would not mind at all using
> a goto for this special case of a loop with multiple exits.
> Some languages have a special construct for this, but if
> this is lacking, then really the goto is as clear as anything
> and avoids duplicating a test.

hmm...  Would you care to explain how this variable is annoyingly
obfuscating, or do you prefer to make unsupported assertions ;)  I did
consider using gotos, but I didn't think that this problem warranted them.

> Yes, I know some people get the heebie-jeebies when they
> see a goto, but just remember you weren't born this way,
> it is learned behavior, and it can be unlearned. Almost
> every style rule should be considered as a guide, and the
> really skilled programmer is one who does not have to rely
> on absolute rules like "Never use a goto", and instead knows
> enough to discriminate.

My first programming language was BASIC.  So please do not assume that I
dislike gotos in fact I actually agree with you that the above rule is silly
and that style rules are guidelines.  Perhaps you should have politely asked
why I decided not to use gotos.  It would have been more constructive and
better received.  (Remember this isn't necessary my advice it could have
been your mother's)

> Code like
>
> for J in 1.. 10 loop
>    if Condition then goto Loop_Interrupted;
>    ....
> end loop;
>
> --  Here if loop ends normally
>
> ...
> return;
>
> --  Here if loop ends abnormally
>
> <<Loop_Interrupted>>
> ...
> return;
>
>
> reads quite clearly to me, and I would be surprised and a
> bit puzzled by any programmer to whom it did NOT read
> clearly.

Yes provided that the loop is short and uncomplicated (which in this case it
is ;).  However, the use of a for loop sets up the expectation that the loop
is going to execute a predetermined amount of times.  Therefore putting
other exit conditions inside of a for loop is misleading to the reader.  A
while loop also carries similar expectations, but a general loop construct
does set up such expectations, and thus the reader expects that they are
going to be defined inside the loop.  This is why my code is constructed as
it is.  I wanted the exit conditions to be precisely and clearly defined.
Since both the for and while loop carried unwanted expectation I didn't use
them.  Now I guess I should explain why I used and exit when and an if block
instead of the gotos that Dr. Dewar seems so fond of advocating.  First,
exits are what you normally use to exit out of a loop.  Second, gotos tend
to set off warning bells when a reader encounters them, and I didn't feel
that the code was doing anything that deserved to alarm the reader.  Third,
I figured that the compiler would remove the additional check since
Interrupted remains constant after the loop has been exited.

><SNIP>

> I think I mentioned before running into a COBOL programmer
> who hated gotos but had no hesitation in writing a STOP RUN
> verb deeply embedded into his program :-)

Although I am not familiar with COBOL's syntax, if STOP RUN is an something
like BREAK or STOP then it makes perfect sense to use it instead of a goto
THE_END equivalent, since label names don't have to tell the truth.  ( I
know the joke is that the programmer didn't believe the two were equivalent
;)

> Sometimes I have seen goto allergic people do this in Ada
> too, interfacing the exit routine!

Find it amusing that you attach these jokes in reply to my posting given
that they bear no relevance what so ever since I am clearly not allergic to
gotos.  So clearly there is no reason to go on a crusade.

Re: checking a loop execution

[Robert Dewar]

In article <3901fc68.0@silver.truman.edu>,
  "Chad R. Meiners" <crmeiners@hotmail.com> wrote:
> Find it amusing that you attach these jokes in reply to my
> posting given that they bear no relevance what so ever since I
> am clearly not allergic to gotos.  So clearly there is no
> reason to go on a crusade.


Sorry, you misunderstood in taking my comments personally, I
was not the least implying what you think about gotos, I have
no idea, and no way of knowing, I was just making general
comments about people's attitudes in general, using the
example you gave as a starting point. The "you" in my message
was not Chad :-) it was just a general comment to those who
get a sick feeling in their stomache when they see a goto.
If you are not one of those, the "you" does not apply!

The "crusade" is a useful one, because the programming field
is afflicted with people who don't really understand principles
and try to replace them with simple absolute rules. These
absolute rules are almost always detrimental (I won't say
always, because then that would be a self referential
criticism :-)

P.S. You ask for substantiantion that I find something
obfuscatory. Hard to give, since this is most certainly a
subjective reaction. The statement is 100% true (that is,
I definitely find the use of boolean variables to represent
control state in this way unnecessarily confusing, and almost
always prefer to restate things so that control state is
represented by the instruction pointer location as nature
intended :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: checking a loop execution

[Ehud Lamm]

On Sun, 23 Apr 2000, Robert Dewar wrote:

|The "crusade" is a useful one, because the programming field
|is afflicted with people who don't really understand principles
|and try to replace them with simple absolute rules. These
|absolute rules are almost alwaysdetrimental (I won't say
|always, because then that would be a self referential
|criticism :-)
|

I usually tell my students: "This is not a coocking class, and you are not
going to be given recipes"

P.S
Actually no good coock simply follows recipes. In general a
professional/competent performer always has "operational flexibility" and
good judgement (to make things clear, so as not to fall in the same trap
as another thread: I am NOT talking about "good" judgement, but about
"good judgement"). I am sure Doug Hofstadter would enjoy these
semi-misunderstandings....

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

Re: checking a loop execution

[Ehud Lamm]

Please exuse all the C's inside my "cooking"...

It was a spelling mistake of the word "cook" and not of the other word you
are thinking about. ;-) 

Ehud Lamm mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web 
Check it out and subscribe to the E-List- for interesting essays and more!

Re: checking a loop execution

[Bill Greene]

Chad R. Meiners wrote:
> 
> ....  However, the use of a for loop sets up the expectation that the loop
> is going to execute a predetermined amount of times.  Therefore putting
> other exit conditions inside of a for loop is misleading to the reader.  ...

My expectation would be that "for I in 1 .. N loop" executes *at most* N
times.

-- 
William R. Greene                              1100 Perimeter Park Drive
Ganymede Software, Inc.                                        Suite 104
http://www.ganymede.com                       Morrisville, NC  27560 USA
Phone: (919) 469-0997, ext. 280                      Fax: (919) 469-5553

Re: checking a loop execution

[Andreas Schulz]

pumilia@my-deja.com schrieb:
> 
> Is there a way to check if a loop has been exited before completion or
> if all iterations have been performed?
> In fortran the loop index is increased one last time, at the end of
> the loop, but in Ada that trick cannot be exploited; the index is not
> even defined outside the loop.

If you want too use its value outside the loop, you
might try a while-loop instead :

> procedure loop_test  is
> 
 ivar : integer :=1;
> 
> begin
   while ivar <= 10 loop
     if <condition>  then
>      exit ;
>    end if ;
     ivar := ivar + 1;
>  end loop;
>  put(ivar,2);
> end loop_test;

Re: checking a loop execution

[tmoran]

>I could add a control variable (ivar, in my example) to take care of the
>iteration number when exiting, but that would decrease the peformance
>of my algorithm

  Your loop as shown evaluates <condition>, and increments and tests
i and branches, up to 10 times, but assigns "ivar := i;" just once,
so setting ivar is a small part of the total time.

  If the loop typically has very few iterations, and performance is
a big problem, then you probably ought to unroll the loop anyway.

>In fortran the loop index is increased one last time, at the end of
>the loop,
  Which of course is an extra increment operation, probably not a
lot cheaper than "ivar := i;".

  You could also make your own loop with your own, lasting, control
variable and your own "exit when i > 10;" to more exactly simulate
the Fortran.

Re: checking a loop execution

[Charles Hixson]

tmoran@bix.com wrote:

> >I could add a control variable (ivar, in my example) to take care of the
> >iteration number when exiting, but that would decrease the peformance
> >of my algorithm
>
>   Your loop as shown evaluates <condition>, and increments and tests
> i and branches, up to 10 times, but assigns "ivar := i;" just once,
> so setting ivar is a small part of the total time.

I thought that compilers automatically detected this kind of optimization.
Would unrolling the loop by hand actually be a good idea?  Or would it be an
optimization that defeated itself as frequently as it helped?  (Actually, my
expectation would be that it would defeat itself more often than it helped.)

Re: checking a loop execution

[Geoff Bull]

pumilia@my-deja.com wrote:
> 
> Is there a way to check if a loop has been exited before completion or
> if all iterations have been performed?
> In fortran the loop index is increased one last time, at the end of
> the loop, but in Ada that trick cannot be exploited; the index is not
> even defined outside the loop.
> I could add a control variable (ivar, in my example) to take care of the
> iteration number when exiting, but that would decrease the peformance
> of my algorithm
> 
> Example
> 
> procedure loop_test  is
> 
> ivar : integer;
> 
> begin
>  for i in 1 .. 10 loop
>  if <condition>  then
>   ivar := i;
>   exit ;
>  end if ;
>  end loop;
>  put(ivar,2);
> end loop_test;
> 
> thank you for your suggestions
 
I can't see why th solution you have proposed would cause a
performance problem, but another solution would be to use a
while loop.