Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!rutgers!cmcl2!lanl!cochiti.lanl.gov!jlg From: jlg@cochiti.lanl.gov (Jim Giles) Newsgroups: comp.lang.fortran Subject: Re: Fortran 90 status Message-ID: <23946@lanl.gov> Date: 17 May 91 16:04:57 GMT References: <13372@exodus.Eng.Sun.COM> <23881@lanl.gov> <1991May16.195328.727@casbah.acns.nwu.edu> Sender: news@lanl.gov Distribution: comp Organization: Los Alamos National Laboratory Lines: 45 In article <1991May16.195328.727@casbah.acns.nwu.edu>, ravi@earth.ce.nwu.edu (Ravi Sinha) writes: |> [...] |> Real DO control variables allow you to have loops like: |> DO r = 1,100000,0.1 |> ... |> ENDDO |> |> The replacement with integer DO control variable would be: |> rbegin = 1 |> rint = 0.1 |> DO i=1,1000000 |> r = rbegin + (i-1)*rint |> ... |> ENDDO |> |> Maybe someone can tell me why the second form is better from an |> optimization point of view, and why the first form should be disallowed. The problem is not optimization but accurate trip count calculation. The loop trip count is calculated as follows: trip_count = INT((end - start + stride) / stride) In your first loop, you're going to get the following calculation: trip_count = INT(99999.1/0.1) Since floating point calculations are inexact, the above may give either 999991 or 999990 depending on rounding before the explicit integer truncation. It doesn't matter what the floating point format is nor what the rounding mode is, you can always find a case which produces the wrong answer. Since integer arithmetic must be exact (as long as it's in range), this problem doesn't arise. Note: your integer loop takes too many steps. It corresponds to a float loop which goes from 0.1 to 100000.0 instead of 1 to 100000 by 0.1. Needless to say (but I will anyway), the calculation of INT(1000000/1) is exact. So would the calculation of DO i=1,999991 => INT(999991/1) which would be a correct expression of you first loop. Of course, the above confusion reveals the difficulty with removing float DO loop limits - converting back to integer limits is error prone. J. Giles