[Mpi-forum] First reading: MPI_Count

[Adam T. Moody]

Wow, I should have proof-read my email first.  Lots of typos.  See 
inlined fixes for these.
-Adam

Adam T. Moody wrote:

>Hi Jeff,
>Ugh, this whole chapter (not the count ticket itself) needs major 
>  
>
this whole chapter = the datatypes chapter.

>editing.  It's poorly organized and it talks about and uses deprecated 
>concepts all over the place.  I'll work with Quincey to propose a better 
>version (along with a full set of MPI_Count datatype calls).
>
>Here are some comments for the count ticket.
>
>p 16, line 15
>Change
>    "Derived datatypes can be created representing more elements than 
>can be encoded in a C int or Fortran INTEGER.  MPI_GET_COUNT, 
>MPI_GET_ELEMENTS, and associated functions cannot properly express these 
>quantities.  To overcome this limitation, these quatities are declared 
>to be INTEGER (KIND=MPI_COUNT_KIND) in Fortran.  In C, one uses MPI_Count."
>to
>    "As described above, MPI defines one type to address locations 
>within memory and another type to address locations within a file.  
>However, at times, one needs a single type that can be used to address 
>locations within either memory or a file.  Furthermore, one needs this
>  
>
or a file, and furthermore, one needs this type to encode any value 
stored in a C int or Fortran INTEGER.

>type to also any value stored in a C int or Fortran INTEGER.  For this, 
>MPI defines the datatype MPI_Count in C and INTEGER 
>(KIND=MPI_COUNT_KIND) in Fortran."
>
>p 16, line 23-24
>Change
>    "in a variable of type C int, MPI_Aint, MPI_Offset, or Fortran INTEGER."
>to
>    "in a variable of type int, MPI_Aint, or MPI_Offset in C and Fortran 
>INTEGER, INTEGER(KIND=MPI_ADDRESS_KIND), or INTEGER 
>(KIND=MPI_OFFSET_KIND) in Fortran."
>  
>
in C and of type INTEGER, INTEGER(KIND=MPI_ADDRESS_KIND), or INTEGER 
(KIND=MPI_OFFSET_KIND) in Fortran.

>p 99, line 14-18
>The whole paragraph is all about the old stuff, which just confuses a 
>new reader.  I would just drop it (or move it toward the end), and 
>replace it with something like:
>    "The following functions return the lower bound and the extent of a 
>datatype."
>  
>
It turns out that a statement like this one is listed below the 
functions.  No need to list it twice, so either drop this one or drop 
the similar statement after the functions.

>If on the otherhand we want to leave, it there are some typos (extra 
>period after MPI_TYPE_EXTENT and "address sized integers" probably means 
>MPI_ADDRESS_KIND, so we should just say "larger sized integers" or 
>something like that):
>    "MPI_TYPE_EXTENT. and also return address sized integers" --> 
>"MPI_TYPE_EXTENT and also return larger sized integers"
>I vote to just drop and replace it, though.
>
>Question: What if MPI_TYPE_GET_EXTENT overflows?
>
>p 100, line 48
>    "MPI_TYPE_GET_TRUE_EXTENT and ..." --> "The functions 
>MPI_TYPE_GET_TRUE_EXTENT and ..."
>
>p 105, line 27
>    "query function MPI_GET_ELEMENTS." --> "query functions 
>MPI_GET_ELEMENTS or MPI_GET_ELEMENTS_X."
>
>p 106, line 20
>    "the MPI_GET_COUNT sets the value of count to" --> "the function 
>sets the value of count to"
>
>p 106, line 20
>Move sentence about overflow up to other sentence about MPI_UNDEFINED, 
>and reword it a bit.
>    "Furthermore, if the number of basics elements is an integral number 
>of datatype copies but this magnitude of this value exceeds the limits 
>of the count parameter, then the function sets the value of count to 
>MPI_UNDEFINED."
>  
>
number of *basic* elements ... copies but *the* magnintude of this ...

>-Adam
>
>
>
>Jeff Squyres wrote:
>
>  
>
>>PDFs have been attached to the 2 MPI_Count tickets for a formal reading at the Chicago Forum meeting in 2 weeks:
>>
>>- General MPI_Count ticket
>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/265
>>- "W" versions of some collectives
>> https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/269
>>
>>Remember that the solution we're proposing here is the "minimal" MPI_Count approach: adding a small number of new functions that take MPI_Count arguments so that MPI can claim to fully support arbitrary-sized counts.
>>
>>Enjoy your light reading.  :-)
>>
>> 
>>
>>    
>>
>
>_______________________________________________
>mpi-forum mailing list
>mpi-forum at lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum
>  
>