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

Bader, Reinhold Reinhold.Bader
Mon Aug 14 13:39:00 EDT 2017



> -----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 ...".
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?
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). 

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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7773 bytes
Desc: not available
Url : http://mailman.j3-fortran.org/pipermail/j3/attachments/20170814/82b78c34/attachment.bin 



More information about the J3 mailing list