(j3.2006) (SC22WG5.5932) cobounds inside a CHANGE TEAM

John Reid John.Reid
Mon Aug 14 16:34:15 EDT 2017



Bader, Reinhold wrote:
>
>
>> -----Urspr?ngliche Nachricht-----
>> Von: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-
>> fortran.org] Im Auftrag von John Reid
>> Gesendet: Sonntag, 13. August 2017 17:55
>> An: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
>> Betreff: Re: (j3.2006) (SC22WG5.5932) cobounds inside a CHANGE TEAM
>>
>>
>>
>> Bader, Reinhold wrote:
>>> Hello John,
>>>
>>> yes, it was my understanding that the cobounds should retain their
>>> values across the CHANGE TEAM statement. Since I could not find the
>>> TS' words on this in the
>>> 2015 draft any more, I now also rechecked your N2127. On page 21 you
>>> say that cobounds are readjusted for "big" (the coarray declared
>>> outside the CHANGE
>>> team) ...
>>> so there seems to be potential for confusion.
>>
>> I did not intend this meaning. I am keeping an updated version of N2127
> with
>> a view of issuing a corrected version when there are enough changes to
>> justify this. In this version, I now say
>>
>> "For example, if big has cobounds [1:k*k] and the current team is
> subdivided
>> into k teams of k images, the association part[*] => big allows part to
> have
>> cobounds [1:k] on each new team, whereas the part of big that is in new
>> team i has cobounds in the range (i-1)*k+1:i*k."
>
> I assume the above needs to read "has *cosubscripts* in the range

Whoops! Yes.

...".
> However, this interpretation
> (apart from not being covered by any words in the draft standard) seems to
> imply some problems
> with the handling of this situation.
>
> For one, what happens if the teams are not set up as contiguous subsets of
> the parent team
> e.g. team i might consist of images i, i+k, i+2*k, ...? Then would
> addressing "big" inside the CHANGE TEAM
> oblige the programmer to use the cosubscripts i:i*k:k?

Yes, I think so. In practice, the implementation would disregard the 
change team construct and use the mapping of the team in which the 
coarray was established. Only a debugging compiler would check whether 
the image referenced is in the current team.

> In general, the programmer will not know what cosubscripts to use, because
> the FORM TEAM
> might have happened in a different program unit. And part of the TEAM design
> aim was to avoid
> this situation (which obliges to pass along additional coindex lists).

In this situation, the programmer should use the association syntax.

> With the rule I had in mind, coindexing inside the teams produces the image
> index inside the team
> from the normal rule that cosubscripts vary between lower and upper cobound
> subject to the
> constraint that the team-local num_images() must not be exceeded. This
> limits the need to use an
> association really only in the comparatively few situations where remapping
> of cobounds and/or
> a change in corank is needed. And it seems to me what the para [140:4-5] you
> cite below really seems to get at.

I don't like this. It would mean that big[10], say, would probably map 
to different images outside and inside the change team construct. I 
don't think there are any words in the TS or the standard to suggest this.

Best wishes,

John.

>
> Cheers
> Reinhold
>
>>
>>> I didn't notice the glitch
>>> when I read
>>> the drafts for this - sorry!
>>>
>>> Also, while cosubscript values remain the same inside the CHANGE TEAM,
>>> the resulting image index and therefore the addressed objects are
>>> always relative to the new team - otherwise the ic[i, TEAM=...]
>>> notation would not be needed.
>>
>> I think that without TEAM= the image accessed is always required to be a
>> member of the current team, whereas with TEAM= it is only required to be a
>> member of TEAM. I say this at the top of page 23 of N2127. However, I am
>> having a hard time verifying that we say this in the standard. We have
> this at
>> [140:4:5] "An image selector shall specify an image index value that is
> not
>> greater than the number of images in the team of the image selector, and
>> identifies the image with that index in that team."
>>
>> It looks to me as if an edit is needed to clarify this.
>>
>> Cheers,
>>
>> John.
>>
>>
>>
>>   The associating
>>> entity is
>>> meant for remapping cobounds and corank, and (from the language point
>>> of
>>> view)
>>> independent of the team (although the programmer had better define a
>>> reasonable layout for her/his own sake).
>>>
>>> Cheers
>>> Reinhold
>>>
>>>> -----Urspr?ngliche Nachricht-----
>>>> Von: j3-bounces at mailman.j3-fortran.org [mailto:j3-
>> bounces at mailman.j3-
>>>> fortran.org] Im Auftrag von John Reid
>>>> Gesendet: Freitag, 11. August 2017 16:38
>>>> An: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
>>>> Betreff: Re: (j3.2006) (SC22WG5.5932) cobounds inside a CHANGE TEAM
>>>>
>>>> Reinhold,
>>>>
>>>> The cosubscripts of ic are not altered by entering the CHANGE TEAM
>>>> construct, so the lower cobound remains 2. For cosubscripts relative
>>>> to
>>> the
>>>> new team, an associating entity is needed.
>>>>
>>>> Cheers,
>>>>
>>>> John
>>>>
>>>>
>>>>
>>>> Bader, Reinhold wrote:
>>>>> Dear J3/WG5,
>>>>>
>>>>>
>>>>>
>>>>> consider the following code:
>>>>>
>>>>>
>>>>>
>>>>> PROGRAM co
>>>>>
>>>>>   INTEGER :: ic[2:*]
>>>>>
>>>>>   INTEGER :: mt
>>>>>
>>>>>   TYPE(team_type) :: t
>>>>>
>>>>>
>>>>>
>>>>>   mt = ... ! determine which team the image belongs to
>>>>>
>>>>>   FORM TEAM ( mt, t )
>>>>>
>>>>>   CHANGE TEAM ( t )
>>>>>
>>>>>       WRITE(*,*)  LCOBOUND(ic, 1)
>>>>>
>>>>>   END TEAM
>>>>>
>>>>> END PROGRAM
>>>>>
>>>>>
>>>>>
>>>>> Based on TS 18508 (N2074) [10:29-30], I would expect that all images
>>>>> print "2". However, this edit was rejected (see 16-176r1), and I
>>>>> have not been able to
>>>>>
>>>>> deduce this result from the current draft. Is something missing here?
>>>>>
>>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>> Reinhold
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> J3 mailing list
>>>>> J3 at mailman.j3-fortran.org
>>>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>>>>>
>>>> _______________________________________________
>>>> J3 mailing list
>>>> J3 at mailman.j3-fortran.org
>>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>>>>
>>>>
>>>> _______________________________________________
>>>> J3 mailing list
>>>> J3 at mailman.j3-fortran.org
>>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org
>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>>
>>
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org
>> http://mailman.j3-fortran.org/mailman/listinfo/j3



More information about the J3 mailing list