(j3.2006) a question on cobounds

Aleksandar Donev donev1
Tue Jul 28 12:59:01 EDT 2009


Hello,

As I suspected, this has gained more attention and "doomsday" claims 
than it deserves.

On Tuesday 28 July 2009 07:04, Jim Xia wrote:
> Can you allow an adjustable array to have SAVE attribute like the
> following? subroutine foo (n)
> ? ? ?INTEGER, SAVE :: X(N)
That example is off-base and you are not going to make your case that 
way. For one, it is not implementable and has no use since one has the 
obvious legal, implementable, and long-used:
  INTEGER :: X(N)
For coarrays, the variable coshape is implementable, and there is no 
other alternative (no coarrays on the stack, sadly)!

On Tuesday 28 July 2009 09:23, Bill Long wrote:
> 1) The current flexibility encourages bad, error prone, or difficult
> to maintain code.
So does allowing one the change the bounds during each procedure call, 
something that has been there for a looong time. All 
flexibility "encourages" bad code (i.e., errors).

> 2) Having the cobounds the same on all images enhances the concept
> that the arrays are symmetric across images.
Sure, if we can do it without throwing the baby with the bathwater.

> 3) We require that the cobounds for allocatable coarrays be the same
> across images, so the same requirement for non-allocatable coarrays
> is more consistent.
I argue that this presumed parallel is misguided below.

But first, back to the question of: Is this "feature" useful? Isn't this 
example a good enough justification for this kind of thing:

subroutine sub(m,n)
   integer, intent(in) :: m, n
  ! The images are arranged in a 2D mxn Cartesian grid

   real, save :: x(max_size)[m,n]

  ! etc.
end subroutine

How can you do this if you require the coshapes to match accross images?

Are you going to require that they be initialization expressions, i.e., 
constant? Then you cannot run with different mxn grids at runtime, an 
obvious use. Or are you going to require that m and n be the same in 
every call on every image? This cannot be enforced and seems utterly 
silly.

For allocatable arrays, it is *different*. There is no parallel's as far 
as I can tell. For allocatables, the coshape is contained in the 
descriptor and determined at runtime during allocation. So one can do

   allocate ( x(size)[m,n] )

and then the mxn is remembered. It can be changed dynamically later. It 
is required to match among images because it is implicit in the design 
that there is only one descriptor per allocatable array. It may be 
replicated on each image on some implementations, but it does not have 
to be. It can be shared, and this may speed up implementations (as Bill 
explained).

Best,
Aleks




More information about the J3 mailing list