(j3.2006) Integration of co-arrays with the intrinsic shift functions

[Aleksandar Donev]

Craig Rasmussen wrote:

> So your co-array A(2,3)[4] is a virtual V(2,12) array.
OK. Why not V(8,3)?

>  If it  
> were declared A(2,3)[2,2], then it would be a virtual V(4,6) array.
What if it is A(3)[5,6,7]? Is it a V(15,6,7) virtual array? I am trying 
to understand what you are doing here---the total rank is the max of the 
rank and co-rank?

HPF, the de facto "data parallel" language, uses this kind of 
"partitioned" array approach. Such an approach, however, does not seem 
to me to not be related to co-arrays. For one, HPF is a 
single-thread-of-control-flow model, which CAF certainly is not. The 
CO_SUM et al. intrinsics do not do sums along dimensions of your V(4,6) 
array---they in fact do not mix the dimensions with the codimensions (as 
you do with your multiplications of size with co-size).

If you looked at the addresses of the elements of your funky V(2,12) 
array, it is rather odd. By some strange way, there is larger jumps 
between some of its columns. This is unlike the regular arrays we have 
now, where the stride between columns is constant. Sure, you can come up 
with strange ways of looking at arrays, but if this leads to a (2,12) 
array that is nothing like an ordinary (2,12) array, the practical 
utility is lost. You are better off coding such abstractions 
yourself---the compilers won't optimize it.

I am not saying co-arrays cannot be used to partition a large array into 
pieces. The thing is, you need to keep track of indices and how you 
compose those pieces into some global array. The model isn't setup for 
that, it merely allows you to access those pieces from other images. It 
is not HPF...

Best,
Aleks