(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