(j3.2006) Wednesday papers

Van Snyder van.snyder
Thu Oct 17 00:15:06 EDT 2013


13-298r2:

Something should be said in a note about the possibility that B(n+n) 
might produce an array of a different size from B(2*n), or that B(n+n) 
might always produce the same size array as B(2*n) even if N changes 
rapidly but the processor does the permitted transformation of replacing 
n+n by 2*n.

13-305r1:

Should "declared prior to the interface body" become "declared prior to 
the interface body or accessible in the host scoping unit by host or use 
association"?

13-310r2: No comments

13-311r1:

I have a slight preference for the alternative formulation.

13-312r3:

I have a slight preference for an alternative wording for C583a:

C583a If IMPLICIT NONE with an <implicit-none-spec> of EXTERNAL appears
           within a scoping unit, a procedure referenced in that scoping 
unit or
           in a contained subprogram or BLOCK construct shall be explicitly
           declared to have the EXTERNAL attribute or shall have 
explicit interface.

13-327r2: No comments

13-329r1:

I remain unconvinced of an urgent need for this intrinsic function.  
Unlike the case for CO_REDUCE, I believe it is almost always easy to 
write an efficient reduction.

13-336r1:

{Van 3}:  I don't think the problem of using coarrays with corank>1, 
that was described in the attachment to the original TS ballot, can be 
solved simply by calling a procedure within a CHANGE TEAM construct.  We 
have not provided anything remotely like co-sections.  If one verifies 
that there are 100 images, and has a 10x10 coarray, I do not see how it 
could be parceled out to four teams, each one getting a 5x5 quadrant of 
it, simply by calling a procedure.

I do not see how using allocatable coarrays solves this problem, unless 
one is satisfied by needing "copy-in/copy-out" semantics.

If the rank>1 problem is solved, it might be useful to allow an image to 
be a member of more than one team.  Consider the case where different 
teams work on problems that are related at an interface.  If the images 
adjacent to the interface are allowed to be in both teams, data can be 
exchanged across the interface using event post/wait, without needing to 
know the image number of the interface element in the parent team.  
Rather, each team needs only to know the thickness of the boundary 
layer, which in many applications is a constant.  The boundary layer 
thickness should not be limited to 1.  The rule that no image is a 
member of more than one currently-executing team limits it to zero.

13-340r1: No comments

13-345r1: No comments

13-346r1: No comments

13-356: No comments

13-356: I prefer answer (1).




More information about the J3 mailing list