Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 90 status
Message-ID: <5861@goanna.cs.rmit.oz.au>
Date: 21 May 91 01:10:20 GMT
References: <1991May16.195328.727@casbah.acns.nwu.edu> <1991May20.182514.17651@casbah.acns.nwu.edu>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 72

In article <1991May20.182514.17651@casbah.acns.nwu.edu>, ravi@earth.ce.nwu.edu (Ravi Sinha) writes:
> The point is:
> If you allow a language to have a feature which can be used very
> intuitively, should you remove the feature later on?  If we are 
> dealing with real variables, real DO loop control variables *are*
> the most intuitive choice.

There are two observations to make about this.
(1) It may be "intuitive", but it is almost always WRONG.
    Any use of DO loops with fractional increments is going to give
    you serious porting problems _unless_ you have worked out so very
    carefully the consequences of roundoff for this particular loop
    that it is no longer relevant whether the result is "intuitive"
    or not.
(2) There _is_ a legitimate use for real-valued DO loops on some
    machines.  With IEEE arithmetic, you can represent 53-bit INTEGERS
    as doubles, and integer operations on those values are correct.
    Any machine whose floating-point operations can be shoe-horned into
    Brown's model has _some_ range of integral values which can be
    correctly represented as floats and operated on using floating-
    point arithmetic.  So there can be loops whose end-points are not
    representable as Fortran INTEGERs, but where the number of iterations
    is reasonable, and a loop using DOUBLE can work just fine.

    However, such loops are anything but portable.  The range of
    integral values correctly handled by DOUBLE arithmetic is highly
    machine-dependent (as for that matter is the range of integral
    values correctly handled by INTEGER arithmetic).

> So, do you want to leave the onus of 
> being correct on the compiler writers, or on the end users?

The onus remains where it always has been.
Compiler writers are responsible for correct compilers.
Program writers are responsible for correct programs.
For non-integral loops, the *only* person/people who has/have the
information required to demonstrate that such a loop is correct
is/are the programmers, _not_ the compiler writers.

> How about requiring that all real DO control variables should be 
> evaluated in extended precision (R*16), and the result passed back in 
> REAL or DOUBLE as the case may be.  Would this take care of roundoff 
> errors in all cases?

Of *course* it wouldn't!

IEEE "extended precision" numbers are 80 bits long (REAL*10, as it
were).  Why should a Fortran system be obliged to include a software
implementation of 128-bit arithmetic just so people can write DO
loops without thinking about what they are doing?

> And how does the overhead compare with using integer DO variables
> and calculating the REAL variable from it?

Except on machines having 128-bit hardware, the integer approach
is *MUCH* cheaper.

As for the example concerning tick marks on a scale; it's a funny 
thing, but I've seen several statistics packages written in Fortran,
and there are several algorithms published in the literature, and
do you know, using a safe (integer) loop really isn't that hard.
It would not have been advantageous to those programs.

> To make peace with those who have considered me to be sigularly
> incompetent:  Through years of habit, I never use real DO variables.
> This is why it didn't occur to me that increment size of 0.1 is 
> not a very good choice for this example.

That fact that it didn't occur to someone who is confident of his
competents is a good indication that it is a risky construct, no?
-- 
There is no such thing as a balanced ecology; ecosystems are chaotic.