Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!unixhub!stanford.edu!unix!Teknowledge.COM!uw-beaver!rice!paco
From: paco@rice.edu (Paul Havlak)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 90 status
Message-ID: <1991May21.012431.7127@rice.edu>
Date: 21 May 91 01:24:31 GMT
References: <1991May16.195328.727@casbah.acns.nwu.edu> <JKORPELA.91May17111428@vipunen.hut.fi> <1991May20.174853.25490@unixg.ubc.ca> <1991May20.182514.17651@casbah.acns.nwu.edu>
Sender: news@rice.edu (News)
Organization: Rice University
Lines: 59
Originator: paco@miranda.rice.edu


The biggest problem with real-valued DO-variables is that they don't really 
exist.  Offering them as part of the syntax is confusing to users of the 
language.

Iteration, like subscripting, is an integer concept.  One cannot enter 
a DO-loop a fractional number of times, any more than one can reference
a fractional element of an array.  The standard requires subscript
expressions to be integer.  Unfortunately, it is more cryptic about the
processing of DO-loops.

In essence, the standard requires that real-valued DO-variables be shadowed 
with an integer-valued iteration count.  This can have the confusing effect
of terminating a DO-loop while the DO-variable is still in range.

ANSI X3.9-1978 FORTRAN 77, page 11-7 defines the execution of a
a DO-loop as follows (taking minimal expository liberties):

	DO <label> <DO-variable> = <init>, <term> [, <inc>]
		...     /  DO-    \
<label>		...     \  range  /

	Let T be the type of the DO-variable.  On execution of the
	DO-header, evaluate the expressions and convert them to type T:

		INIT = T(<init>)
		TERM = T(<term>)
		INC  = T(<inc>)

	Assign the iteration count to be

		MAX( INT( (<term> - <init> + <inc>)/<inc>), 0)

	Assign the DO-variable

		<DO-variable> = INIT

	Loop-control processing executes the DO-range if the iteration 
	count is not zero.

	Each time that the normal end of the DO-range is reached, 
	incrementation processing

		* decrements the iteration count by one

		* increments the DO-variable by INC

		* continues execution with loop-control processing

In other words, the real-valued DO-variable is just a sideshow.  Even 
worse, because the computation of the DO-variable and the iteration 
count are required to be independent, implementations are forced by
the standard and the realities of floating-point to allow them to get
out of sync (e.g., if the increment is small enough relative to the bounds).

Gedankenexperiment:
	What happens if the bounds and increment are such that adding INC to
	INIT has no effect, but the iteration count can still be evaluated 
	as an integer?