Message from discussion Array constructors and kinds
Received: by 10.68.129.169 with SMTP id nx9mr11146010pbb.2.1330472533735;
Tue, 28 Feb 2012 15:42:13 -0800 (PST)
From: Robin Vowels <robin.vow...@gmail.com>
Subject: Re: Array constructors and kinds
Date: Tue, 28 Feb 2012 15:42:13 -0800 (PST)
References: <1330137388.326978@athprx03> <9qr2b6F17uU1@mid.individual.net>
X-Trace: posting.google.com 1330472533 14908 127.0.0.1 (28 Feb 2012 23:42:13 GMT)
NNTP-Posting-Date: Tue, 28 Feb 2012 23:42:13 +0000 (UTC)
Injection-Info: b18g2000vbz.googlegroups.com; posting-host=220.127.116.11; posting-account=S_MdrwoAAAD7T2pxG2e393dk6y0tc0Le
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729),gzip(gfe)
Content-Type: text/plain; charset=ISO-8859-1
On Feb 29, 2:27=A0am, Tobias Burnus <bur...@net-b.de> wrote:
> On 02/28/2012 03:08 PM, Robin Vowels wrote:
> > On Feb 28, 10:03 pm, Tobias Burnus<bur...@net-b.de> =A0wrote:
> >> However, I found a better example:
> >> =A0 =A0 =A0real(selected_real_kind(radix=3D2)) :: b
> >> =A0 =A0 =A0real(selected_real_kind(radix=3D10)) :: d
> >> =A0 =A0 =A0call proc([b, d])
> >> where "b" is a binary floating-point number (radix=3D2) and "d" is a
> >> decimal floating-point number (radix=3D10). And to make it complete,
> >> "proc" is a generic name for two specific subroutines, one taking a
> >> binary and one taking a decimal floating point number as argument.
> >> However, the same issue occurred for the program as is - with an
> >> implicit interface of "proc".
> >> I do not see how this can be solved without a type spec. And, thus, I
> >> don't think that PL/I has solved this 45+ years ago.
> > No typespec is required. =A0See my earlier Fortran example.
> I disagree:
Did you forget my previous example?
"Alternatively, it can be written as
"v =3D (/ v, real( (/ 1, 2, 3, 4, 5 /) ) /)"
which, as I pointed out previously, can be used with pre-F2003
compilers (and subsequent compilers, of course).
> First, will [b, d] be an array of binary or of decimal floating-point
> numbers? At least Fortran does not allow one to mix different
> types/kinds in a single array.
We know this. My example shows how it would be written.
> There is also no obvious solution like
> promoting [1, 1.0, 2.0d0] to an array with double-precision elements.
Use the REAL function, as in my earlier example, with kind.
> And in this example, you cannot even make use of the left-hand side as
> there is none.
No need to, as that's irrelevant anyway.
The LHS (if any) cannot influence what is inside an array constructor
on the RHS -- or any kind of RHS, for that matter.
> Secondly, the Fortran standard mandates:
> C4103 (R469) If type-spec is omitted, each ac-value expression in the
> array-constructor shall have the same declared type and kind type
So? And my example doesn't?
> "If type-spec is omitted, each ac-value expression in the array
> constructor shall have the same length type parameters; in this case,
> the declared type and type parameters of the array constructor are those
> of the ac-value expressions."
That's not relevant. It's a requirement in Fortran, but not in PL/I,
> Thus, I maintain: One needs a type-spec because the standard mandates
> one and because the there is no obvious choice to which one
> promotes/converts elements in case of mixing binary/decimal values.
See my example.
> In case of mixing integers with reals or single with double precision
> reals, but also in case of character strings, I concur that one could
> implemented a version where different values are automatically promoted
> - be it from integer to real, from single to double precision or to the
> longest string.
Indeed it could have been, and should have been.
> > BTW, a type-spec isn't required in Fortran; it's an option.
> But only if all types are the same (cf. Fortran 2008's C4103).
See my example.
> > (Earlier, I gave an example of mixed types, without using a typespec,
> > which can be used with compilers earlier than F2003.)
> Well, compilers assume lazy users and allow with default options more
> than the standard mandates. One can argue whether that's good or not. In
> any case, if your compiler allows it with standard checking enabled, it
> is broken.
It's not broken. Did you try my example?
> Additionally, I am sure that for the character example, several (most?
> all?) compilers won't create an array using the longest string, but
> choose, e.g., the length of the first element or of the last argument,
> or of an element where the length is known at compile time or ...
They won't -- nut under the current rules.
I pointed out that it _could_ have been implemented by
choosing the length of the longest string.
> Searching - at run time! - for the element with the longest string
> length is a waste of CPU cycles as it is known that the length of all
> strings is the same. The user has promised that.
Only because those who designed the standard insisted that all the
lengths be the same. That, however, is a pain in the neck,
as typically the lengths are going to be different. (consider a table
of English words.)