Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!uflorida!stat!stat.fsu.edu!mccalpin
From: mccalpin@masig1.ocean.fsu.edu (John D. McCalpin)
Newsgroups: comp.lang.fortran
Subject: Re: dpANS Fortran 8x
Message-ID: <MCCALPIN.89Jun28094619@masig1.ocean.fsu.edu>
Date: 28 Jun 89 14:46:19 GMT
References: <2724@elxsi.UUCP> <6105@microsoft.UUCP>
Sender: news@stat.fsu.edu
Distribution: usa
Organization: Supercomputer Computations Research Institute
Lines: 58
In-reply-to: bobal@microsoft.UUCP's message of 19 Jun 89 17:05:38 GMT

In an earlier article, Bob Allison quotes Bob Corbett:
>>
>> KIND selectors are an inherently implementation-dependent feature.
>> [...] I can easily imagine
>>		              INTEGER(8)
>>meaning an 8-bit integer in one implementation, a 48-bit integer in another,
>>and a 64-bit integer in another.  The requirement should be strengthened to
>>be the capability to detect and report all uses of KIND selectors.
>						Bob Corbett

Bob Allison replies:
>
>This is an entirely separate problem, and a fundamental weakness in the
>KIND specifier: what does it mean?  Not only is it implementation dependent,
>but it is in units that are implementation dependent.  In other words, 
>you are best served by always using symbolic constants whenever using 
>KIND parameters (which almost defeats their use).

I have found this to be perhaps the most ridiculous "feature" of the
new draft.  The fact that the _values_ of the KIND selectors are
implementation dependent is just *begging* for people to write
non-portable code.  If the programmer uses long, explicit names for
these integer types, then the resulting code would be almost
unreadable.  For example, suppose that the machine supports a
floating-point precision which is less than the default precision (a
la Cyber 205).  Then the "correct" specification of an operation would
be something like:

	INTEGER, PARAMETER:: HALF_PRECISION=SELECTED_REAL_KIND(5,30)
	REAL, ARRAY(100), KIND=HALF_PRECISION:: A,B,C

	A = B + 2.0_HALF_PRECISION*C	! the constant must be half-precision
					! to prevent unwanted conversion
					! of everything to default real.

Is anyone really going to write code like this?
Of course, even the non-portable version is almost unintelligible:

	REAL, ARRAY(100), KIND=1:: A,B,C

	A = B + 2.0_1*C

I certainly don't want to have to *read* code that has this sort of
gibberish scattered throughout....

Finally, of course, there is the most general and correct approach:

	INTEGER, PARAMETER:: HALF_PRECISION=SELECTED_REAL_KIND(5,30)
	REAL, ARRAY(100), KIND=HALF_PRECISION:: A,B,C
	REAL, PARAMETER, KIND=HALF_PRECISION:: TWO=2.0	! implied conversion

	A = B + TWO*C		! finally, I get to do some calculations!

I'm still waiting for the committee's response to my suggestion that
an option be provided to specify the default precision of literal
constants.
--
John D. McCalpin - mccalpin@masig1.ocean.fsu.edu - mccalpin@nu.cs.fsu.edu