From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Dec 4 00:46:57 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 78ED43582D0; Wed, 4 Dec 2013 00:46:57 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109]) by www.open-std.org (Postfix) with ESMTP id D918E356B6E for ; Wed, 4 Dec 2013 00:46:56 +0100 (CET) Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rB3Nknsl009560 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Tue, 3 Dec 2013 15:46:52 -0800 Subject: (j3.2006) (SC22WG5.5122) Response for letter ballot on N1996 From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: WG5 Content-Type: multipart/mixed; boundary="=-IFgIGlW74eCxnqyQ0sQw" Organization: Yes Date: Tue, 03 Dec 2013 15:46:49 -0800 Message-ID: <1386114409.16299.155.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-30.el6) X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk --=-IFgIGlW74eCxnqyQ0sQw Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Please answer the following question "Is N1996 ready for forwarding to SC22 as the DTS?" in one of these ways. 3) No, for the following reasons: I have been on holiday in Asia for most of November. I have not had the time to study the entire DTS in detail. Therefore, I comment here on only one aspect of the DTS. I remain unconvinced that teams have been correctly designed, but if so they are not sufficiently well described. The phrase "image indices are relative to the current team" in Subclause 5.1 does not adequately explain what parts of a coarray are accessible in a subteam. The mapping from coarray coelements accessible in the parent team, and their cosubscripts, to coarray coelements accessible in the subteam, and their cosubscripts, needs to be more explicitly explained. More importantly, it is not possible to change the coextents of leading codimensions of coarrays of rank greater than one when a subteam commences execution. This means that teams are not very useful if one has coarrays of corank greater than one. Finally, it is not possible for a subteam to access more coelements than the number of images in the subteam. This makes it difficult to handle cross-boundary effects in, say, an elliptic PDE problem, without using cosubscripts relative to a specific ancestor team. This is a fundamentally bad idea, that is antithetical to one of the reasons advanced for providing teams: software reuse. Reinhold proposed a RECODIMENSION statement. This would presumably have an effect on leading codimensions analogous to the effect of a DIMENSION statement on leading dimensions of a non-coarray dummy argument of a procedure. The attached text file provides more detail concerning what I believe to be the problems, and proposes a scheme of coarray coassociation similar to the association established by the ASSOCIATE construct. Best wishes Van --=-IFgIGlW74eCxnqyQ0sQw Content-Disposition: attachment; filename="201-wvs-008.txt" Content-Type: text/plain; name="201-wvs-008.txt"; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit WG5/N19xx To: WG5 Subject: Accessing team coarrays in subteams From: Van Snyder Date: 27 June 2013 1. Problem description ---------------------- Within a subteam created by a CHANGE TEAM construct, it is desired to access a portion of a coarray belonging to the parent team, using cosubscripts such that the range of accessible coelements, taken in coarray coelement order, depends upon the subteam. It is undesirable to require the subteam to be aware of the mapping from coelements of the parent coarray to coelements germane to the subteam. The phrase "image indices are relative to the current team" in Subclause 5.1 does not adequately explain what parts of a coarray are accessible in a subteam. The mapping from coarray coelements accessible in the parent team, and their cosubscripts, to coarray coelements accessible in the subteam, and their cosubscripts, needs to be more explicitly explained. If this is described elsewhere, it needs to be in Subclause 5.1. For example, if one forms a subteam using 1+mod(this_image(),2) for the , it is not obvious that the coelements of coarrays accessible in each subteam are the odd-numbered and even-numbered coelements of coarrays in the parent team, taken in the parent team's coarray coelement order (a concept we have not defined). More importantly, it is impossible to change the coextents of the leading codimensions of coarrays of rank greater than one when a subteam commences execution. Suppose one has 100 images and a coarray with coextent [1:10,1:10]. Suppose one wishes to divide the current team into four subteams of 25 members each, each accessing a quadrant of the coarray with coextent [1:5,1:5]. All subteams would access the coarray with the leading coextent declared in the parent team, in this case [1:10]. We have no concept of copointers, coassociation, copointer corank remapping, cosections, or coassociation during procedure reference or execution of an ASSOCIATE or SELECT TYPE statement, analogous to pointer association, argument association, or construct association for arrays. This means either that teams are not very useful if one has arrays of corank greater than one, or a subteam must be made aware of at least some properties of the mapping from the parent team to the subteam, analogously to the way that subprograms having explicit-shape dummy arguments need to be told what parts of leading dimensions to use. A third problem is that it is not possible to access coelements outside the mapping for the current team, or for parts of a coarray to be accessible in more than one subteam using subteam-relative cosubcripts. For example, in the above problem, one might wish to divide the [1:10,1:10] coarray into pieces with coextents [1:6,1:6], with the first team having coelements [1:6,1:6], the second having [4:10,1:6], the third having [1:6,4:10], and the last having [4:10,4:10]. This makes it difficult to handle cross-boundary effects between regions of, say, an elliptic PDE problem. The present DTS requires the use of cosubscripts whose values apply to a specific ancestor team. This is a fundamentally bad idea, that is antithetical to one of the reasons advanced for providing teams: software reuse. 3. Proposal ----------- An addition to the syntax of the CHANGE TEAM statement, analogous to the ASSOCIATE statement, could specify coassociation. For example, assuming s = 1+mod(this_image(),2) one might use the following to associate A1 with the odd (even) coelements of A. change team ( t(s), a1 => a[s:*:2] ) ! Herein, A1 is a coarray that is coassociated with the ! odd-numbered coelements of A in subteam 1 and the even-numbered ! ones in subteam 2, of which there are n/2, and therefore ! cosubscripts of A1 in the range 1:n/2 access the expected ! coelements of A. ... end team The mapping from A to A1 is not necessarily the same as the mapping established by the FORM TEAM statement. If it is necessary for the mappings to correspond, that should be explicitly required. A STAT= specifier value could indicate a mismatch. In the case of a coarray of corank greater than one, one might compute cobounds that depend upon the subteam id, and do something like change team ( t2(s1,s2), c1 => c[i1:i2,j1:*] ) One could calculate the cosubscripts to handle the problem of a cosection belonging to more than one subteam. For example, one subteam might have i1:i2 == 1:6 while another has i1:i2 == 4:10. This would be inconsistent with the proposition that the mapping shall correspond to the one implied by the FORM SUBTEAM statements that created the team variable. Vector cosubscripted cosections would not be an insurmountable problem here (until A1 or C1 is an actual argument corresponding to a coarray dummy argument, which should perhaps be prohibited), because the processor clearly could see the vector. --=-IFgIGlW74eCxnqyQ0sQw--