[Mpi-22] Fwd: [MPI Forum] #2: MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS ambiguities introduced in MPI-2.1

[Jeff Squyres]

FYI -- this contentious ticket has been withdrawn.  The reviewers and  
myself all missed a statement immediately preceding the language  
neutral bindings of MPI_TYPE_GET_CONTENTS that says:

     The actual arguments used in the creation call for a datatype can  
be obtained from the call:

Hence, the current text is perfectly clear on what the behavior should  
be.

Begin forwarded message:

> From: "MPI Forum" <mpi-22_at_[hidden]>
> Date: February 10, 2009 3:43:48 PM PST
> Subject: Re: [MPI Forum] #2: MPI_TYPE_GET_ENVELOPE and  
> MPI_TYPE_GET_CONTENTS ambiguities introduced in MPI-2.1
>
> #2: MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS ambiguities  
> introduced in
> MPI-2.1
> -------------------------------- 
> +-------------------------------------------
> Reporter:  jsquyres             |        Owner:  jsquyres
>    Type:  Text (only) changes  |       Status:  closed
> Priority:  Waiting for reviews  |    Milestone:  2009/02/09 San Jose
> Version:  MPI 2.2              |   Resolution:  Withdrawn
> Keywords:                       |
> -------------------------------- 
> +-------------------------------------------
> Changes (by jsquyres):
>
>  * status:  assigned => closed
>  * resolution:  => Withdrawn
>
>
> Old description:
>
>> == Description ==
>>
>> Sep 8 2008 Straw Vote
>>
>> || return 0|| don't return 0 || Abstain ||
>> || 17 || 1 || 9 ||
>>
>> MPI-2.1 introduced an ambiguity in the interpretation of what
>> MPI_TYPE_GET_CONTENTS is supposed to return.  Specifically: MPI-2.1
>> introduced that user-defined datatypes could be created with zero  
>> counts
>> for datatypes.  The ambiguity originates from two sections of text:
>>
>> * MPI-2.1: p78:18-20
>>     Most datatype constructors have replication count or block length
>> arguments. Allowed values are nonnegative integers. If the value is  
>> zero,
>> no elements are generated in the type map and there is no effect on
>> datatype bounds or extent.
>> * MPI-2.1: p107:47-48
>>     The datatypes returned in array_of_datatypes are handles to  
>> datatype
>> objects that are equivalent to the datatypes used in the original
>> construction call.
>>
>> If datatype constructors accept 0-count datatype arguments that are
>> supposed to have "no elements are generated in the type map" and "no
>> effect on datatype bounds or extent", should MPI_TYPE_GET_CONTENTS  
>> return
>> those 0-count datatypes in array_of_datatypes?  After all,
>> MPI_TYPE_GET_CONTENTS says that array_of_datatypes is supposed to  
>> contain
>> handles to datatype objects that are equivalent to the datatypes  
>> used in
>> the original construction call (which used 0-count datatypes).
>>
>> A similar problem exists with MPI_TYPE_GET_ENVELOPE; does  
>> num_datatypes
>> contain a count of all the zero-count datatypes specified in the
>> constructor?
>>
>> == History ==
>>
>> Ambiguity was accidentally introduced in MPI-2.1 (verified in July  
>> 2008
>> Forum meeting).
>>
>> == Proposed Solution ==
>>
>> Change MPI-2.1 p107:47-48 from:
>>
>>  The datatypes returned in array_of_datatypes are handles to datatype
>> objects that are equivalent to the datatypes used in the original
>> construction call.
>>
>> to
>>
>>  The datatypes returned in array_of_datatypes are handles to datatype
>> objects that are equivalent to the significant datatypes used in the
>> original construction call (datatypes with zero count or zero  
>> blocklength
>> are not considered significant).
>>
>> == Impact on Implementations ==
>>
>> Implementations that return zero-count or zero-blocklength  
>> datatypes will
>> need to be updated to not return them.
>>
>> == Impact on Applications / Users ==
>>
>> Applications will need to recognize that zero-count/zero-blocklength
>> datatypes will not be returned from MPI_TYPE_CONTENTS.  This is not
>> expected to be a burden because the the intended consumers of
>> MPI_TYPE_CONTENTS are looking for the "significant" datatypes (vs.
>> looking for insignificant datatypes that will just be discarded).
>>
>> == Alternative Solutions ==
>>
>> * Change it so that MPI_TYPE_CONTENTS specifically returns zero- 
>> count/
>> zero-blocklength datatypes.  This does not seem useful to the  
>> expected
>> consumers of MPI_TYPE_CONTENTS.
>> * Allow MPI implementations to either return the zero-count  
>> datatypes or
>> not.  From the user perspective, this is the same as requiring MPI
>> implementations to return the zero-count datatypes because the
>> application will need to check for zero-count datatypes in
>> array_of_datatypes.
>>
>> == Entry for the Change Log ==
>>
>> Section 4.1.13 on page 104.  Remove ambiguity regarding zero-count
>> datatypes with MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS.
>
> New description:
>
> == Description ==
>
>  Sep 8 2008 Straw Vote
>
> || return 0|| don't return 0 || Abstain ||
> || 17 || 1 || 9 ||
>
> MPI-2.1 introduced an ambiguity in the interpretation of what
> MPI_TYPE_GET_CONTENTS is supposed to return.  Specifically: MPI-2.1
> introduced that user-defined datatypes could be created with zero  
> counts
> for datatypes.  The ambiguity originates from two sections of text:
>
>  * MPI-2.1: p78:18-20
>      Most datatype constructors have replication count or block length
> arguments. Allowed values are nonnegative integers. If the value is  
> zero,
> no elements are generated in the type map and there is no effect on
> datatype bounds or extent.
>  * MPI-2.1: p107:47-48
>      The datatypes returned in array_of_datatypes are handles to  
> datatype
> objects that are equivalent to the datatypes used in the original
> construction call.
>
> If datatype constructors accept 0-count datatype arguments that are
> supposed to have "no elements are generated in the type map" and "no
> effect on datatype bounds or extent", should MPI_TYPE_GET_CONTENTS  
> return
> those 0-count datatypes in array_of_datatypes?  After all,
> MPI_TYPE_GET_CONTENTS says that array_of_datatypes is supposed to  
> contain
> handles to datatype objects that are equivalent to the datatypes  
> used in
> the original construction call (which used 0-count datatypes).
>
> A similar problem exists with MPI_TYPE_GET_ENVELOPE; does  
> num_datatypes
> contain a count of all the zero-count datatypes specified in the
> constructor?
>
> == History ==
>
> Ambiguity was accidentally introduced in MPI-2.1 (verified in July  
> 2008
> Forum meeting).
>
> == Proposed Solution ==
>
> Change MPI-2.1 p107:47-48 from:
>
>   The datatypes returned in array_of_datatypes are handles to datatype
> objects that are equivalent to the datatypes used in the original
> construction call.
>
> to
>
>   The datatypes returned in array_of_datatypes are handles to the same
>
> handles to datatype objects that are identical to the datatypes used  
> in
> the original construction call, including any zero-count datatypes  
> that
> were specified in the original datatype constructor.
>
> == Impact on Implementations ==
>
> Implementations may need to be updated to save a copy of the datatypes
> passed to datatype constructor functions.
>
> == Impact on Applications / Users ==
>
> Applications will need to handle zero-count datatypes in what they get
> back from MPI_TYPE_CONTENTS.  This is not expected to be a burden  
> because
> the user created the datatype with a zero-count datatype anyway.
>
> == Alternative Solutions ==
>
>  * Change it so that MPI_TYPE_CONTENTS specifically excludes zero- 
> count
> datatypes.  This does not seem to be consistent.
>  * Allow MPI implementations to either return the zero-count  
> datatypes or
> not.  From the user perspective, this is the same as requiring MPI
> implementations to return the zero-count datatypes because the  
> application
> will need to check for zero-count datatypes in array_of_datatypes.
>
> == Entry for the Change Log ==
>
> Section 4.1.13 on page 104.  Remove ambiguity regarding zero-count
> datatypes with MPI_TYPE_GET_ENVELOPE and MPI_TYPE_GET_CONTENTS.
>
> --
>
> Comment:
>
> It turns out that all of us missed the following statement MPI-2.1
> p107:1-2:
>
>   The actual arguments used in the creation call for a datatype can be
> obtained from the call:
>
> (followed by the language neutral binding for MPI_TYPE_GET_CONTENTS)
>
> Hence, I withdraw this ticket -- the current text is perfectly clear  
> on
> exactly what the behavior should be (sorry Dick!).
>
> -- 
> Ticket URL: <https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/2#comment:26 
> >
> MPI Forum <https://svn.mpi-forum.org/>
> MPI Forum


-- 
Jeff Squyres
Cisco Systems