(j3.2006) Comments on some of the comments

Malcolm Cohen malcolm
Wed Aug 9 23:52:26 EDT 2017


Hi Jon,

 

CHANGE TEAM uses a team-value, not a team-variable.  And you can assign team-variables across images, so preventing CHANGE TEAM from using a coindexed variable would not solve anything for CHANGE TEAM (anyway I don?t see any edit to CHANGE TEAM here).

 

Preventing FORM TEAM from writing to a coindexed variable does not solve anything either, as it can be assigned to a coarray on another image.  I stand by my comments on FORM TEAM: it might be unusual (weird or strange even), but it?s not obviously wrong to have a coindexed variable here.  As it does not prevent misuse, merely make it microscopically harder to misuse, I don?t see the point in introducing a gratuitous incompatibility.

 

> you could do a change team to a team variable that describes a team which the executing image is not a member of.  Do you think these things should be allowed?

 

But these edits don?t achieve disallowing it.  The teams in image selectors are already required to be ancestor teams, which means the executing image has to be a member (otherwise it?s not an ancestor team); in SYNC TEAM the executing image is already explicitly stated to be required to be a member.  So those are already ok.

 

CHANGE TEAM does not clearly state that the executing image has to be a member of the team identified by team-value, apart from it being an immediate consequence of ?current team for the statements of the CHANGE TEAM block is the team identified by the team-value?; if the executing image is not a member of that team, there is a direct contradiction, so by clause 4, that is not conforming.  We don?t like to rely on clause 4 for implicit requirements, so the wording in CHANGE TEAM should be improved to make that requirement explicit.  (Fiddling with FORM TEAM would just put a tiny (and avoidable) roadblock in the way, without actually making any explicit requirement on CHANGE TEAM.)

 

So I think the edit you need is on [188:7], just after the text I quoted above, insert ?The executing image shall be a member of the team identified by team-value.?  Since this is already an implicit requirement of the immediately preceding sentence, it is an Editorial change, not actually a Technical one.  And not incompatible with the coarray TS either!

 

As an extra Editorial change, I recommend also [213:4] ?specified team? -> ?team identified by team-value?.

 

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

 

From: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Steidel, Jon L
Sent: Thursday, August 10, 2017 11:45 AM
To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
Cc: John Reid <John.Reid at stfc.ac.uk>; Bill Long <longb at cray.com>
Subject: Re: (j3.2006) Comments on some of the comments

 

Hi Malcolm,

 

These edits have gone back and forth between Bill and John Reid and myself.  I started all this by expressing my concern that there is no restriction on a CHANGE TEAM or FORM TEAM using a coindexed team-variable.  My concern is that a FORM TEAM could define a different images team variable, or you could do a change team to a team variable that describes a team which the executing image is not a member of.  Do you think these things should be allowed?  John and Bill did not think that was the intent.

 

-jon

 

From: j3-bounces at mailman.j3-fortran.org <mailto:j3-bounces at mailman.j3-fortran.org>  [mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Malcolm Cohen
Sent: Wednesday, August 9, 2017 9:53 PM
To: 'fortran standards email list for J3' <j3 at mailman.j3-fortran.org <mailto:j3 at mailman.j3-fortran.org> >
Subject: (j3.2006) Comments on some of the comments

 

[139:29] The assertion that it is not stated that the team value in an image selector has to be defined is false, the standard already states ?shall identify the current or an ancestor team?.  The suggested fix for this non-problem has forgotten that one is allowed to use assignment of team variables (after all, that?s what GET_TEAM is useful for!!!).  Nothing needs to be done here and this technical change would break the language, rendering GET_TEAM unusable for this context.  Do Not Do This.

 

[213:3] This is wrong and completely unworkable.  The claim that something ?is required? and ?has not been stated? is false on the face of it (it?s an internal contradiction!).  The suggested change seems to be imagining that when SYNC TEAM happens, it is the same SYNC TEAM statement being executed on every participating image.  This imagination is false.  In fact the standard already states that the SYNC occurs between SYNC TEAM executions ?specifying the same team?, so there is no problem that needs to be solved here.  It also breaks assignment of team variables for subsequent use in SYNC TEAM, rendering GET_TEAM unusable for this context.  Do Not Do This.

 

[214:27] The team-variables in FORM TEAM would appear to be already required to be separate variables by the segment rules.  There would be nothing wrong in principle with

                FORM TEAM ( myteam(this_image())[1], ?)

which is allowed by the coarray TS.  This usage might be unusual, but it?s not inconceivable or wrong.

 

This would not be a disaster (unlike the two preceding), but it would still be a gratuitous incompatibility with the coarray TS.  Please don?t insert more gratuitous incompatibilities.

 

P.S. I am not planning to participate in the telecon seeing as how it?s at 2am my time?

 

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

 

 

Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20170810/686c5cf7/attachment.html 



More information about the J3 mailing list