(j3.2006) (SC22WG5.5124) image selectors

[Bill Long]

I hope that some clarification will help avoid unnecessary tangents in 
Ballot responses for N1996 in the area of the new image selector 
notation.  I've attached a note on the issues (and lack of issues) 
related to this feature (which I had planned in include in my ballot 
eventually).  A key point is that the capability (arguably useful) that 
Van wants is separable from the mechanics of how the team-modified 
images selectors work.   Hopefully this will be helpful.

Cheers,
Bill


-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101


-------------- next part --------------
Notes on image_selector issues..


In N1996, the TS 18508 draft from J3 meeting 202, the facility
provided by the modified image selectors allows references to coarrays
on images that are not part of the current team. This is enabled by
syntax that specifies a different team that is in effect for that
reference.  The team has to be an ancestor of the current team, and
include the image specified. 

The cobounds for a coarray can only be specified in a declaration or
allocate statement. Changing to a different team does not alter the
cobounds or corank of an existing coarray. A coarray has only one set
of bounds at a given time, and only allocatable coarrays can change
their cobounds during program execution.

The identification of the correct physical PE containing the coarray
being referenced using the new syntax involves two steps: Using the
specified cosubscripts and the current cobounds for the coarray, an
image index is computed. The image index is then converted to a
physical PE by a team-specific mapping.

Suppose a coarray, 

   REAL :: A(:)[N1,N2,*] 

exists (either static, or allocatable and allocated with those
cobounds) on each image on entry to a CHANGE TEAM construct. For
statements executed during execution of the CHANGE TEAM construct:

Case 1: No team is specified in the reference:

   X(:) = A(:)[i,j,k]
 
This reference is relative to the current team. The cobounds used to
compute the image index are the ones that existed when the CHANGE TEAM
construct began.  If the computed image index is outside the range
1..num_images() for the current team, the reference is in error. If
the image index is in the valid range, the mapping between image
indices and physical PE for the current team is used to identify the
physical PE containing the referenced coarray.  The computation of the
correct coarray location is unambiguous in this case, though the
selection of the values [i,j,k] might not be intuitive.


Case 2: An ancestor team, pteam, is specified in the reference:

   X(:) = A(:)[pteam :: i,j,k]

This reference is relative to the team specified by the value of the
team variable pteam. The computation of the image index is exactly the
same as in Case 1, with the current cobounds of A(:) used.  The value
of num_images() used in the range check for a valid image index is the
number of images in team pteam. The image identified has to be an
image that is part of team pteam; otherwise an error occurs.  The
mapping between the computed image index and a physical PE location
for A is the one for team pteam.

For the team-modified image selector syntax to work, the
implementation would need to keep track of the mapping and
num_images() information for all ancestors of the current team, and
associate that with the team variable. This is probably the case
anyway. It is not necessary to keep track of cobound information
separately for each team - that information is tied to the coarray,
not the team.


As noted in N1983, in the comments on the previous TS draft from Van
Snyder, the correct values for the cosubscripts in Case 1 are not
intuitive unless the corank is one. The existing team-modified syntax
in Case 2 does not address that problem.

A facility enabled by a RECODIMENSION statement has been discussed on
coarray-ts to address this problem.  A RECODIMENSION defines the
current cobounds for a coarray that exists during execution of the
construct and is associated with the previously existing coarray of
the same name. The cobounds and corank of the construct coarray may be
different from those of the existing coarray. The association is
similar to argument association. This is superior to actual argument
association in that a procedure call is not involved. How use of this
feature would affect the ability to access the corresponding coarray
on an image outside the current team (using a team-modified image
specifier) is not quite as clear.

Alternatively, a syntax similar to the associate construct, as
suggested by Van, could be employed. That has the advantage of using a
different name for the construct entity, which would permit use of the
original name for accesses outside the current team.