Xref: utzoo comp.lang.modula2:1222 comp.lang.c:15838 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!hc!lanl!jlg From: jlg@lanl.gov (Jim Giles) Newsgroups: comp.lang.modula2,comp.lang.c Subject: Re: "for" loops (was Re: C++ vs. Modula2) Message-ID: <8515@lanl.gov> Date: 28 Jan 89 01:02:21 GMT References: <19579@agate.BERKELEY.EDU> Organization: Los Alamos National Laboratory Lines: 36 From article <19579@agate.BERKELEY.EDU>, by bowles@eris.berkeley.edu (Jeff A. Bowles): > [...] > 1. It's not restrictive on the types of the indices, because it defines a > more general construct. If I had a nickel for every time, in Fortran, > that I needed a loop that ran from 0.0 to 1.0 by 0.1 (or the like) and > had to use INTEGER to do it. Or Pascal, which lacked the "step" clause > so that you couldn't increment by more than what the language-designer > wanted. > [...] > Jeff Bowles ALL standard conforming Fortran processors allow the following: DO 10 i=0.0,1.0,0.1 The standard committee now considers this to be a mistake and is likely to remove it in 8x, but for the moment this is a standard feature. It is considered a mistake because the standard doesn't make any constraints on the accuracy of floating-point arithmetic. So the trip count on a loop with floating-point limits is not well-defined. The C for-loop is even worse in this regard - the trip count is not precomputed. Consider the following: for (x=0.0; x<=1.0, x+=0.1) {...} The value of x for each trip through the loop is a sum of 0.1+ ... +0.1, a value which suffers round-off or truncation on each successive add. If the four operations in the computation of the Fortran trip count lead to ambiguous results, the 11 adds in the above are even worse. For a loop from 0.0 to 1000.0 by 0.01 on a 32-bit floating-point machine, the round-off of the last 100 adds is comparable to the increment itself! This may be another reason for the undesireable feature in C of assuming double precision as the default floating-point. J. Giles