From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Dec 10 00:52:09 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 666783582C9; Tue, 10 Dec 2013 00:52:09 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by www.open-std.org (Postfix) with ESMTP id 706E83582A1 for ; Tue, 10 Dec 2013 00:52:06 +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 rB9Nq4FQ028795 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Mon, 9 Dec 2013 15:52:05 -0800 Subject: Re: (j3.2006) (SC22WG5.5137) image selectors From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: sc22wg5 In-Reply-To: <52A64FCB.3080901@cray.com> References: <20131204000730.3A09F3582D0@www.open-std.org> <1386116202.16299.164.camel@math.jpl.nasa.gov> <52A39BE9.2060403@cray.com> <20131209230519.94A273582C9@www.open-std.org> <52A64FCB.3080901@cray.com> Content-Type: text/plain; charset="ISO-8859-1" Organization: Yes Date: Mon, 09 Dec 2013 15:52:04 -0800 Message-ID: <1386633124.13428.37.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-30.el6) Content-Transfer-Encoding: 7bit X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk On Mon, 2013-12-09 at 17:18 -0600, Bill Long wrote: > > On 12/9/13 5:05 PM, Van Snyder wrote: > >> OK. Reinhold's revised ballot reworded this idea in terms of the image > >> >index in the initial team rather than physical processors. That is > >> >arguably better terminology to use. The image's image index in the > >> >initial team never changes throughout the program execution. > > > I assume this refers to Reinhold's message of 2 December. That > > message's attachment did not include any comments concerning 5.1. The > > problem is that "image indices are relative to a specified team" at > > [9:5-6] does not give any information concerning the correspondence > > between coindices in parent teams and subteams, nor does "cosubscripts > > See [11:21-22]. The program can explicitly specify the new image index. > Otherwise it is processor dependent. I think that means that in most applications one must specify NEW_INDEX. Why make it optional? Instead of "assigned by the processor" the term "processor dependent" should be used. Better yet would be to specify the mapping from parent team to subteam. If NEW_INDEX is not specified, is there really a difficulty with specifying, for example, that the image indices for the subteam are in the same order as the image indices in the parent team, so that image index 1 for the subteam applies to the image with the smallest image index in the parent team that becomes part of the subteam, etc.? > > are interpreted as if the current team were the team specified by > > " at [11:4]. Without standardizing this, indexing with > > respect to ancestor teams is not useful. I tried in vain to find this > > mapping in 5.3 -- 5.5. The addition of DISTANCE to THIS_IMAGE doesn't > > seem to do the job.