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

[Van Snyder]

On Sat, 2013-12-07 at 16:06 -0600, Bill Long wrote:
> 
> On 12/3/13 6:16 PM, Van Snyder wrote:
> > On Tue, 2013-12-03 at 18:02 -0600, Bill Long wrote:
> >> 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.
> >
> > This is an important step that is not explained in the TS, or at least
> > if it is, I couldn't find it.  It needs to be in Subclause 5.1.
> >
> 
> OK.  Reinhold's revised ballot reworded this idea in terms of the image 
> index in the initial team rather than physical processors.  That is 
> arguably better terminology to use.  The image's image index in the 
> initial team never changes throughout the program execution.

I assume this refers to Reinhold's message of 2 December.  That
message's attachment did not include any comments concerning 5.1.  The
problem is that "image indices are relative to a specified team" at
[9:5-6] does not give any information concerning the correspondence
between coindices in parent teams and subteams, nor does "cosubscripts
are interpreted as if the current team were the team specified by
<team-variable>" at [11:4].  Without standardizing this, indexing with
respect to ancestor teams is not useful.  I tried in vain to find this
mapping in 5.3 -- 5.5.  The addition of DISTANCE to THIS_IMAGE doesn't
seem to do the job.

By the way, the edit for 13.7.165 at [33:7] needs "a" before "member".

> I think a key point here is that the image is physically unchanged by 
> changing teams - it is still executing on the same processor/thread and 
> has all the same variables as before.  What changes are the current 
> number of images and the current  image index (i.e the values of 
> NUM_IMAGES() and THIS_IMAGE()).  As side effects, the scope of 
> collective operations is (possibly) changed (if the number of images 
> changed), and the mapping from image index to physical processor 
> (probably) changed because the image index value (probably) changed but 
> the underlying processor/thread did not.
> 
> Cheers,
> Bill
>