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

John Reid John.Reid
Sun Aug 13 11:54:54 EDT 2017



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 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



More information about the J3 mailing list