>Date: Thu, 16 Mar 2000 14:22:23 -0800 (PST)
>Subject: Question re real & complex
>From: Richard Maine <[log in to unmask]>
>To: [log in to unmask]
>Dan Nagle writes:
> > I know Fortran processors are supposed to have
>> a complex for each real, but a language-lawyer :-)
>> might argue that a third real kind is an
>> extension, not requiring a corresponding complex.
>Because if the third real kind is claimed to be an extension and thus
>not count as one of the kinds fully supported by the processor, then I
>think the processor had better conform to 1.4 of the standard, which
>requires that the processor "contains the capability to detect and
>report the use within a submitted program unit of kind type values
>(4.3) not supported by the processor."
>I also think that selected_real_kind is non-conforming if it returns
>a kind type value that isn't fully supported.
I think that the case is stronger than that.
There is one (and only one) function that provides the kind --
namely, SELECTED_REAL_KIND -- for floating-point values,
whether they be REAL or COMPLEX.
There isn't a SELECTED_COMPLEX_KIND.
It would be peculiar indeed if you could use this function
(SELECTED_REAL_KIND) to get the kind of some REAL,
and then to use it only to find that
the program crashes on compilation because the kind isn't
available for COMPLEX.
I'm certain that the committee had this in mind when they
framed the rule requiring that a COMPLEX type be provided
for each REAL type.
How do you dig half a hole?
>To your original question, I'm afraid I don't know a practical
>answer. I think my legalese answer would be to make use of
>selected_real_kind, which isn't allowed to return a positive value
>that couldn't be used in a complex. I'm just afraid that my
>legalistic answer is likely to be wrong in practice.
>Richard Maine [log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|