Re: do while: most elegant or efficient

From: Oyvind Sylta (oyvind.sylta_at_iku.sintef.no)
Date: 01/25/05 

Date: Tue, 25 Jan 2005 10:29:23 +0100

In the do while case I described there were a couple of concerns that I had
before posting it:

- is it possible to not evaluate the second part of the test (after .and.)
if the first ellement results in .false.
    I interpret all your answers as simply: no, not in the present standard
(including F2003), but maybe later

- is the do while faster or slower than a loop construct as described below.
    I always used the loop until I tried to change to do while, mostly
because it looks "more elegant", in particular in the way you stop the
looping.
    From the responses, it seems I may as well go back to using the do-enddo
construct with if-tests inside.

Oyvind

"Richard E Maine" <nospam@see.signature> wrote in message
news:nospam-35241B.08374924012005@news.supernews.com...
> In article <1106567704.860706.304420@f14g2000cwb.googlegroups.com>,
> beliavsky@aol.com wrote:
>
> > The reason the first code may not work is that according to the Fortran
> > standard, the second conditional involving c(n:n) may be evaluated
> > before the first one is, resulting in trying to access an out-of-bound
> > element of c.
>
> A minor correction. The problem is not with what order the conditionals
> are evaluated in. The problem is in *WHETHER* the c(n:n) part is
> evaluated. It doesn't matter whether this evaluation is before or after
> anything else. It is perfectly possible that the first conditional could
> be evaluated first, but then that the second one could still be
> evaluated anyway. I think that phrasing it as a matter of order of
> evaluation is misleading, in that it implies that there is
> short-circuiting, but possibly with the direction of the
> short-circuiting variable.
>
> Otherwise I'm completely "with" Beliavsky on this. Use the index
> intrinsic for the specific case mentioned. If you have a more
> complicated condition that doesn't fit the index intrinsic, then I'd use
> a DO loop with EXIT. And I wouldn't use WHIEL here - I think that just
> complicates life (though some people disagree). Something like
>
> loop: DO n = 1 , max
> if (whatever) exit loop
> end do loop
>
> Adjust as appropriate if this gives an answer off by 1 from whatever you
> want. And be sure to check the boundary condition of the fallthrough
> case. (In this form, the fallthrough case gives n=max+1.
>
> P.S. I'd personally avoid the variable name max. It conflicts with an
> intrinsic, which is legal but confusing. And in a large program, the
> name is likely to be too broad (lots of things running around that might
> have max_something_or_other). But I assume this short sample is
> abstracted anyway.
>
> --
> Richard Maine | Good judgment comes from
experience;
> email: my first.last at org.domain | experience comes from bad judgment.
> org: nasa, domain: gov | -- Mark Twain

Relevant Pages

  • Re: future of lazy programming
    ... evaluation semantics will loop with strict evaluation. ... rather than strict vs lazy evaluation. ...
    (comp.lang.functional)
  • Re: beginner, idiomatic python
    ... Python re-evaluates the loop range on every loop, ... Python does short-circuit evaluation of conditions, ...
    (comp.lang.python)
  • Re: beginner, idiomatic python
    ... is it defined that the variable is evaluated for every loop? ... Python re-evaluates the loop range on every loop, ... Python does short-circuit evaluation of conditions, ...
    (comp.lang.python)
  • Re: In-Out Parameters for functions
    ... > evaluation doesn't make sense. ... Of what use is arbitrariness to the ... much of the constraint checking that Ada requires would be ... for I in A'Range loop ...
    (comp.lang.ada)
  • Re: do while: most elegant or efficient
    ... It doesn't matter whether this evaluation is before or after ... a DO loop with EXIT. ... if exit loop ... And be sure to check the boundary condition of the fallthrough ...
    (comp.lang.fortran)