(j3.2006) (SC22WG5.5123) Response for letter ballot on N1996

[Van Snyder]

Please answer the following question "Is N1996 ready for forwarding to
SC22 as the DTS?" in one of these ways.

3) No, for the following reasons:

I have been on holiday in Asia for most of November.  I have not had the
time to study the entire DTS in detail.  Therefore, I comment here on
only one aspect of the DTS.

I remain unconvinced that teams have been correctly designed, but if so
they are not sufficiently well described.  The phrase "image indices are
relative to the current team" in Subclause 5.1 does not adequately
explain what parts of a coarray are accessible in a subteam.  The
mapping from coarray coelements accessible in the parent team, and their
cosubscripts, to coarray coelements accessible in the subteam, and their
cosubscripts, needs to be more explicitly explained.

More importantly, it is not possible to change the coextents of leading
codimensions of coarrays of rank greater than one when a subteam
commences execution.  This means that teams are not very useful if one
has coarrays of corank greater than one.

Finally, it is not possible for a subteam to access more coelements than
the number of images in the subteam.  This makes it difficult to handle
cross-boundary effects in, say, an elliptic PDE problem, without using
cosubscripts relative to a specific ancestor team.  This is a
fundamentally bad idea, that is antithetical to one of the reasons
advanced for providing teams: software reuse.

Reinhold proposed a RECODIMENSION statement.  This would presumably have
an effect on leading codimensions analogous to the effect of a DIMENSION
statement on leading dimensions of a non-coarray dummy argument of a
procedure.

The attached text file provides more detail concerning what I believe to
be the problems, and proposes a scheme of coarray coassociation similar
to the association established by the ASSOCIATE construct.

Best wishes
Van

-------------- next part --------------
                                                               WG5/N19xx
To:      WG5
Subject: Accessing team coarrays in subteams
From:    Van Snyder
Date:    27 June 2013

1. Problem description
----------------------

Within a subteam created by a CHANGE TEAM construct, it is desired to
access a portion of a coarray belonging to the parent team, using
cosubscripts such that the range of accessible coelements, taken in
coarray coelement order, depends upon the subteam.  It is undesirable to
require the subteam to be aware of the mapping from coelements of the
parent coarray to coelements germane to the subteam.

The phrase "image indices are relative to the current team" in Subclause
5.1 does not adequately explain what parts of a coarray are accessible
in a subteam.  The mapping from coarray coelements accessible in the
parent team, and their cosubscripts, to coarray coelements accessible in
the subteam, and their cosubscripts, needs to be more explicitly
explained.  If this is described elsewhere, it needs to be in Subclause
5.1.

For example, if one forms a subteam using 1+mod(this_image(),2) for the
<team-id>, it is not obvious that the coelements of coarrays accessible
in each subteam are the odd-numbered and even-numbered coelements of
coarrays in the parent team, taken in the parent team's coarray
coelement order (a concept we have not defined).

More importantly, it is impossible to change the coextents of the
leading codimensions of coarrays of rank greater than one when a subteam
commences execution.  Suppose one has 100 images and a coarray with
coextent [1:10,1:10].  Suppose one wishes to divide the current team
into four subteams of 25 members each, each accessing a quadrant of the
coarray with coextent [1:5,1:5].  All subteams would access the coarray
with the leading coextent declared in the parent team, in this case
[1:10].  We have no concept of copointers, coassociation, copointer
corank remapping, cosections, or coassociation during procedure
reference or execution of an ASSOCIATE or SELECT TYPE statement,
analogous to pointer association, argument association, or construct
association for arrays.  This means either that teams are not very
useful if one has arrays of corank greater than one, or a subteam must
be made aware of at least some properties of the mapping from the parent
team to the subteam, analogously to the way that subprograms having
explicit-shape dummy arguments need to be told what parts of leading
dimensions to use.

A third problem is that it is not possible to access coelements outside
the mapping for the current team, or for parts of a coarray to be
accessible in more than one subteam using subteam-relative cosubcripts. 
For example, in the above problem, one might wish to divide the
[1:10,1:10] coarray into pieces with coextents [1:6,1:6], with the first
team having coelements [1:6,1:6], the second having [4:10,1:6], the
third having [1:6,4:10], and the last having [4:10,4:10].  This makes it
difficult to handle cross-boundary effects between regions of, say, an
elliptic PDE problem.  The present DTS requires the use of cosubscripts
whose values apply to a specific ancestor team.  This is a fundamentally
bad idea, that is antithetical to one of the reasons advanced for
providing teams: software reuse.

3. Proposal
-----------

An addition to the syntax of the CHANGE TEAM statement, analogous to the
ASSOCIATE statement, could specify coassociation.

For example, assuming s = 1+mod(this_image(),2) one might use the
following to associate A1 with the odd (even) coelements of A.

  change team ( t(s), a1 => a[s:*:2] )
    ! Herein, A1 is a coarray that is coassociated with the
    ! odd-numbered coelements of A in subteam 1 and the even-numbered
    ! ones in subteam 2, of which there are n/2, and therefore
    ! cosubscripts of A1 in the range 1:n/2 access the expected
    ! coelements of A.
    ...
  end team

The mapping from A to A1 is not necessarily the same as the mapping
established by the FORM TEAM statement.  If it is necessary for the
mappings to correspond, that should be explicitly required.  A STAT=
specifier value could indicate a mismatch.

In the case of a coarray of corank greater than one, one might compute
cobounds that depend upon the subteam id, and do something like

  change team ( t2(s1,s2), c1 => c[i1:i2,j1:*] )

One could calculate the cosubscripts to handle the problem of a
cosection belonging to more than one subteam.  For example, one subteam
might have i1:i2 == 1:6 while another has i1:i2 == 4:10.  This would be
inconsistent with the proposition that the mapping shall correspond to
the one implied by the FORM SUBTEAM statements that created the team
variable.

Vector cosubscripted cosections would not be an insurmountable problem
here (until A1 or C1 is an actual argument corresponding to a coarray
dummy argument, which should perhaps be prohibited), because the
processor clearly could see the vector.