[Mpi-forum] First reading: MPI_Count

[Adam T. Moody]

Hi Jeff,
Ugh, this whole chapter (not the count ticket itself) needs major 
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 
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."

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."
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."

-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.  :-)
>
>  
>