Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!unmvax!unm-la!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: "for" loops
Message-ID: <8618@lanl.gov>
Date: 31 Jan 89 00:36:20 GMT
References: <15692@mimsy.UUCP>
Organization: Los Alamos National Laboratory
Lines: 56

From article <15692@mimsy.UUCP>, by chris@mimsy.UUCP (Chris Torek):
> [...]
>>The C for-loop is even worse in this regard - the trip count is not
>>precomputed.
> 
> That this is worse is mere opinion (or perhaps contentiousness).

It's worse in the sense that the loop without a clear trip count calculation
may not terminate at all!
 
Consider the following:

      for (x=0.0; x<=1.0, x+=0.0000001) {...}

The intent is for 10 million steps.  But if IEEE single is used, the
increment becomes a no-op at some point.  An explicit trip count calculation
would at least not exhibit this problem.  Rounding during the divide step
would probably select the wrong trip count - but it wouuld still select
a finite one.

(before you shout that a 10 million trip loop is an unrealistic example,
I should point out that such things are standard fare around here.) 

> [...]
> which in F77 can be written (I will use `WHILE' here for conciseness
> and to avoid those blasted statement numbers)

Why not use the Fortran 8x style DO - END DO pair: no statement labels
there :-).> 

> [...]
> Any programmer worth his pay is aware of the method by which the trip
> count is determined, and will write the appropriate code in the appropriate
> situation.  It is true that situations demanding floating point loop
> counters are rare.

Here's where we part company in a big way. I oppose ANY language construct
that requires the programmer to know internals about how the construct
is performed.  Both Fortran and C (and most everything else for that matter)
already have too many such constructs.  It is probable that a compiled
language CAN'T be written with SOME such constructs - but let's keep
them at a minimum.

For example, it's bad enough that in the above example you really have to 
write:

      for (i=0, i<10000000, i++) { x=i*0.0000001; ...}

Now, the relative error in the value x during execution remains fairly
constant (rather than accumulating as in the incremented version).  Many
Fortran compilers actually implement DO loops with real limits in the
above manner.  The standard should really specify that this should be
done so the user needn't worry about it.

J. Giles
Los Alamos