<html><body>
<p><tt>How about this? </tt><br>
<br>
<br>
<tt> Most datatype constructors have replication count or block<br>
length arguments. Allowed values are nonnegative integers. <br>
If the value is zero, no elements are generated in the type map</tt><br>
<tt> and there is no effect on datatype bounds or extent.</tt><br>
<br>
<tt>I think it is bounds and extent that were questioned. I think it is self evident that a zero value cannot affect the type signature. </tt><br>
<br>
Dick Treumann - MPI Team/TCEM <br>
IBM Systems & Technology Group<br>
Dept 0lva / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846 Fax (845) 433-8363<br>
<br>
<br>
<tt>mpi-21-bounces@cs.uiuc.edu wrote on 01/29/2008 12:43:02 PM:<br>
<br>
> This is a proposal for MPI 2.1, Ballot 4.<br>
> <br>
> This is a follow up to:<br>
> Block lengths of zero in MPI Datatypes <br>
> in <a href="http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-">http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-</a><br>
> errata/index.html<br>
> with mail discussion in<br>
> <a href="http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-">http://www.cs.uiuc.edu/homes/wgropp/projects/parallel/MPI/mpi-</a><br>
> errata/discuss/blklenzero/<br>
> ___________________________________<br>
> <br>
> Proposal:<br>
> Add the following paragraph in MPI 1.1, Sect. 3.12, page 62, <br>
> after line 2 (i.e., after ... "of the types defined by Typesig."):<br>
> <br>
> Most datatype constructors have replication count or block<br>
> length arguments. Allowed values are nonnegative integers. <br>
> If the value is zero, no elements are generated in the type map<br>
> nor in the type signature for this entry in the argument list. <br>
> <br>
> MPI 1.1, Sect 3.12.1, MPI_TYPE_HINDEXED, page 67, line 22-24 read:<br>
> IN count number of blocks – also number of entries in <br>
> array_of_displacements and array_of_blocklengths<br>
> (integer)<br>
> but should read:<br>
> IN count number of blocks – also number of entries in <br>
> array_of_displacements and array_of_blocklengths<br>
> (nonnegative integer)<br>
> <br>
> <br>
> MPI 1.1, Sect 3.12.1, MPI_TYPE_STRUCT, page 68, line 19-22 read:<br>
> IN count number of blocks (integer) – also number <br>
> of entries in arrays array_of_types, <br>
> array_of_displacements and array_of_blocklengths<br>
> IN array of blocklength number of elements in each <br>
> block (array of integer)<br>
> but should read:<br>
> IN count number of blocks (nonnegative integer) – also number <br>
> of entries in arrays array_of_types, <br>
> array_of_displacements and array_of_blocklengths<br>
> IN array of blocklength number of elements in each <br>
> block (array of nonnegative integer)<br>
> <br>
> <br>
> MPI 2.0, Sect 4.14.1, MPI_TYPE_CREATE_HINDEXED, page 66, line 36-38 read:<br>
> IN count number of blocks – also number of entries in <br>
> array_of_displacements and array_of_blocklengths<br>
> (integer)<br>
> but should read:<br>
> IN count number of blocks – also number of entries in <br>
> array_of_displacements and array_of_blocklengths<br>
> (nonnegative integer)<br>
> <br>
> <br>
> MPI 2.0, Sect 4.14.1, MPI_TYPE_CREATE_STRUCT, page 67, line 14-18 read:<br>
> IN count number of blocks (integer) – also number <br>
> of entries in arrays array_of_types, <br>
> array_of_displacements and array_of_blocklengths<br>
> IN array of blocklength number of elements in each <br>
> block (array of integer)<br>
> but should read:<br>
> IN count number of blocks (nonnegative integer) – also number <br>
> of entries in arrays array_of_types, <br>
> array_of_displacements and array_of_blocklengths<br>
> IN array of blocklength number of elements in each <br>
> block (array of nonnegative integer)<br>
> ___________________________________<br>
> <br>
> Rationale for this clarification and modification:<br>
> The outcome of zero-count entries in the type map was not defined.<br>
> For this, a clarification was needed. <br>
> The interfaces of HINDEXED and STRUCT was inconsistent to the rest <br>
> derived datatype routines. This was probably due to editing errors.<br>
> A meaning of negative values was never defined not intended.<br>
> Therefore, portable applications could not use negative values.<br>
> These editing errors are fixed by this proposal.<br>
> ___________________________________<br>
> <br>
> <br>
> I hope, I could catch all the problems Jesper mentioned in his mail.<br>
> <br>
> Best regards<br>
> Rolf<br>
> <br>
> On Tue, 29 Jan 2008 15:02:10 +0100<br>
> Jesper Larsson Traeff <traff@it.neclab.eu> wrote:<br>
> ><br>
> >Dear Rolf,<br>
> ><br>
> >(thanks for all the work you are putting into this!)<br>
> ><br>
> >On Tue, Jan 29, 2008 at 12:47:14PM +0100, Rolf Rabenseifner wrote:<br>
> >> Reply is off-line from the mailing list.<br>
> >> <br>
> >> Dear Jesper and Bill,<br>
> >> <br>
> >> I believe that this is not a topic for the one and final shot <br>
> >> of MPI 2.1 Ballot 4 in the next (March 2008) meeting.<br>
> >> Therefore, I would propose to handle it in MPI 2.2.<br>
> >> <br>
> >In the MPI-1 document (p.66, p.68) index and struct types are treated<br>
> >differently. For index, blocklength is an array of non-negative integers<br>
> >(p.66, line 12), for struct, just an array of integers (p. 68, line 22).<br>
> >Same inconsistency for the new MPI-2 types, p.66 and p.67.<br>
> >I believe that this should at least be made consistent.<br>
> ><br>
> >I would also be in favor of a small remark that 0 blocklengths are allowed,<br>
> >with the remarks that these are (of course) not included in the type map.<br>
> ><br>
> >Btw, I will be coming to the meeting in March<br>
> ><br>
> >best regards<br>
> ><br>
> >Jesper<br>
> ><br>
> >> Jesper, you have not been at Jan meeting. Therefore a short background.<br>
> >> We decided, that MPI 2.1 is mainly the combining of the MPI 1.1<br>
> >> and 2.0 documents to one MPI 2.1 standard.<br>
> >> Additionally the existing MPI 1.1 errata, and the MPI-2 electonically<br>
> >> voted Ballots 1 & 2, and the Jan. meeting Ballot 3 and the March meeting<br>
> >> Ballot 4 are included. Topics that do not get final official reading<br>
> >> in these meetings are forwarded to MPI 2.2. <br>
> >> <br>
> >> Therefore I try to have mainly items in Ballot 3 and 4 that do not<br>
> >> need longer discussions and that are mainly obvious, i.e., that can<br>
> >> be shown on one or two slides together with needed background infos.<br>
> >> <br>
> >> Implication for me: I do not put your item on my MPI 2.1 agenda.<br>
> >> <br>
> >> Okay?<br>
> >> <br>
> >> Best regards<br>
> >> Rolf<br>
> >> <br>
> >> On Mon, 23 Apr 2007 17:10:35 +0200<br>
> >> Jesper Larsson Traeff <traff@ccrl-nece.de> wrote:<br>
> >> ><br>
> >> >(ps: also sent to mpi-core@mpi-forum.org - did anybody get it from there?)<br>
> >> ><br>
> >> >Dear MPI forum,<br>
> >> ><br>
> >> >an old discussion (July-September 2001) concluded that blocklengths of<br>
> >> >value zero are allowed in MPI indexed and struct types. Reading the<br>
> >> >standard, both text and specification (p.66ff), such "blocks" generate<br>
> >> >no entries in the corresponding type maps, at least this seems to be<br>
> >> >the idea - and implementations like mpich2 follow this interpretation,<br>
> >> >while the original MPICH for instance did not, and maybe with some right?<br>
> >> ><br>
> >> >The question is what a derived datatype is intended to specify. If<br>
> >> >it specifies just a type map, then clearly blocks of length zero should<br>
> >> >simply be treated as not being there, and the resulting type map alone<br>
> >> >defines the extent, lower and upper bounds of the datatype. But if a <br>
> >> >derived datatype is intended as specifying a layout in memory, zero <br>
> >> >length blocks could possibly have another meaning (as markers oflocations<br>
> >> >in the layout), and in addition to the type map affect the extent, <br>
> >> >lower and upper bound of the datatype. <br>
> >> ><br>
> >> ><br>
> >> >A concrete example<br>
> >> ><br>
> >> > displacements(1)=1<br>
> >> > displacements(2)=0<br>
> >> > lengths(1)=1<br>
> >> > lengths(2)=0<br>
> >> ><br>
> >> > call mpi_type_indexed(2,lengths,displacements,MPI_INTEGER,newtype,code)<br>
> >> > call mpi_type_commit(newtype,code)<br>
> >> ><br>
> >> >In the first interpretation (datatypes specify type map) the above has<br>
> >> >extent 4 (assuming MPI_INTEGER is 4 bytes) and lower bound 4<br>
> >> ><br>
> >> >In the second interpretation (datatypes specify layout) the above would<br>
> >> >have lower bound 0 and extent 8<br>
> >> ><br>
> >> ><br>
> >> >The point is that in the first interpretation (which is the one at least<br>
> >> >implicitly prescribed by the standard) the layout that was <br>
> possibly intended <br>
> >> >by the user ("something starting at displacement soandso" - <br>
> irrespective of<br>
> >> >whether there is actual data at displacement soandso) can be quite<br>
> >> >arbitrarily collapsed. In an application where datatypes are generated<br>
> >> >automatically, it might be a high burden on the user to take care of<br>
> >> >the special cases arising by some blocklenghts just happening to<br>
> >> >be zero (either he would have to resize, or to put in explcit <br>
> >> >MPI_LB/MPI_UB markers).<br>
> >> ><br>
> >> >A point could therefore be made for treating blocks of length<br>
> >> >zero still as "markers" in the specification of a layout - as did for<br>
> >> >instance the original MPICH implementation. Some changes in the text<br>
> >> >would be necessary to put this interpretation on a firm foundation.<br>
> >> >That is not the intention here, but only to see if there are opinions<br>
> >> >on this issue? A suggestion would be to add a short paragraph stating<br>
> >> >that zero blocklengths are allowed, and what their effects and <br>
> side-effects<br>
> >> >are.<br>
> >> ><br>
> >> >Jesper<br>
> >> ><br>
> >> ><br>
> >> >Minor clarifications:<br>
> >> ><br>
> >> >p.63, l.39, p.66, l.12, and p.67, l.25 have "nonnegative integer" <br>
> >> >blocklengths, but p. 68, l.22 only has "integer". <br>
> >> >To be consistent P. 68, l.22 should also be "nonnegative integer" <br>
> >> >(negative blocklenghts don't make sense)<br>
> >> ><br>
> >> >(as already pointed out by Steven Huss-Lederman) The specification<br>
> >> >p.66, l.46ff and similarly for MPI_Type_hindexed and MPI_Type_struct<br>
> >> >makes little sense (well, is plain wrong) when some B[i] is <br>
> actually zero. <br>
> >> >First, l.46 forces some elements into the type map [ (type_0,<br>
> disp_0+D[0]) ,,,]<br>
> >> >that shouldn't be there (blocks of length zero shouln't give rise to any<br>
> >> >elements in the type map), and also l.48 has no real meaning <br>
> >> >when B[0]. Better would be to add two lines after l.48 giving the general<br>
> >> >case:<br>
> >> ><br>
> >> >(type_0,disp_0+D[i]*ex),...,(type_{n-1},disp_{n-1}+D[i]*ex),...,<br>
> >> >(type_0,disp_0+(D[i]+B[i]-1)*ex,...,(type_{n-1},disp_{n-1}+(D[i]<br>
> +B[i]-1)*ex,<br>
> >> ><br>
> >> >with the proviso that this is empty if B[i]==0 (or even more formally<br>
> >> >precise/correct)<br>
> >> ><br>
> >> <br>
> >> <br>
> >> <br>
> >> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@hlrs.de<br>
> >> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530<br>
> >> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832<br>
> >> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner<br>
> >> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)<br>
> <br>
> <br>
> <br>
> Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner@hlrs.de<br>
> High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530<br>
> University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832<br>
> Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner<br>
> Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)<br>
> _______________________________________________<br>
> mpi-21 mailing list<br>
> mpi-21@cs.uiuc.edu<br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21">http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21</a><br>
</tt></body></html>