Intended meaning of zero blocklengths in MPI_Type_indexed/MPI_Type_create_struct

[Jesper Larsson Traeff <traff@xxxxxxxxxxxx>]

(ps: also sent to mpi-core@xxxxxxxxxxxxx - did anybody get it from there?)

Dear MPI forum,

an old discussion (July-September 2001) concluded that blocklengths of
value zero are allowed in MPI indexed and struct types. Reading the
standard, both text and specification (p.66ff), such "blocks" generate
no entries in the corresponding type maps, at least this seems to be
the idea - and implementations like mpich2 follow this interpretation,
while the original MPICH for instance did not, and maybe with some right?

The question is what a derived datatype is intended to specify. If
it specifies just a type map, then clearly blocks of length zero should
simply be treated as not being there, and the resulting type map alone
defines the extent, lower and upper bounds of the datatype. But if a 
derived datatype is intended as specifying a layout in memory, zero 
length blocks could possibly have another meaning (as markers of locations
in the layout), and in addition to the type map affect the extent, 
lower and upper bound of the datatype. 


A concrete example

  displacements(1)=1
  displacements(2)=0
  lengths(1)=1
  lengths(2)=0

  call mpi_type_indexed(2,lengths,displacements,MPI_INTEGER,newtype,code)
  call mpi_type_commit(newtype,code)

In the first interpretation (datatypes specify type map) the above has
extent 4 (assuming MPI_INTEGER is 4 bytes) and lower bound 4

In the second interpretation (datatypes specify layout) the above would
have lower bound 0 and extent 8


The point is that in the first interpretation (which is the one at least
implicitly prescribed by the standard) the layout that was possibly intended 
by the user ("something starting at displacement soandso" - irrespective of
whether there is actual data at displacement soandso) can be quite
arbitrarily collapsed. In an application where datatypes are generated
automatically, it might be a high burden on the user to take care of
the special cases arising by some blocklenghts just happening to
be zero (either he would have to resize, or to put in explcit 
MPI_LB/MPI_UB markers).

A point could therefore be made for treating blocks of length
zero still as "markers" in the specification of a layout - as did for
instance the original MPICH implementation. Some changes in the text
would be necessary to put this interpretation on a firm foundation.
That is not the intention here, but only to see if there are opinions
on this issue? A suggestion would be to add a short paragraph stating
that zero blocklengths are allowed, and what their effects and side-effects
are.

Jesper


Minor clarifications:

p.63, l.39, p.66, l.12, and p.67, l.25 have "nonnegative integer" 
blocklengths, but p. 68, l.22 only has "integer". 
To be consistent P. 68, l.22 should also be "nonnegative integer" 
(negative blocklenghts don't make sense)

(as already pointed out by Steven Huss-Lederman) The specification
p.66, l.46ff and similarly for MPI_Type_hindexed and MPI_Type_struct
makes little sense (well, is plain wrong) when some B[i] is actually zero. 
First, l.46 forces some elements into the type map [ (type_0,disp_0+D[0]) ,,,]
that shouldn't be there (blocks of length zero shouln't give rise to any
elements in the type map), and also l.48 has no real meaning 
when B[0]. Better would be to add two lines after l.48 giving the general
case:

(type_0,disp_0+D[i]*ex),...,(type_{n-1},disp_{n-1}+D[i]*ex),...,
(type_0,disp_0+(D[i]+B[i]-1)*ex,...,(type_{n-1},disp_{n-1}+(D[i]+B[i]-1)*ex,

with the proviso that this is empty if B[i]==0 (or even more formally
precise/correct)