[mpi-21] Reading of Chapter 4

[Jesper Larsson Traeff <traff@xxxxxxxxxxxx>]

Dear all,

I have read Chapter 4 - here are my corrections, comments and suggestions
(only things not already in the errata sheet from Jan 30, 2002). There is
little of great substance.

I have prefixed the comments as follows:
(typo) - uncontroversial typo/misspelling, should be corrected
(suggestion) - suggestion for alternative wording/extra comment
(addition) - suggestion for addition
(comment) - my comment, not intended for standard document

General typo: is "implementor" (with an "o") a word in US English?
Shouldn't it be "Implementers"? (as in "Advice to implementers")

General comments: the chapter is quite awful, and in the longer run I
would be in favor of having the parts (e.g. on datatypes) moved to
the chapters where they belong properly. I think Rolf will be doing some
of this.
I would also suggest having a special chapter in the new 2.1
document summarizing all deprecated functionality (with a short rationale
as to why the function was deprecated)

For mnemonic reasons, I would suggest having all datatype constructors
being of the form

MPI_TYPE_CREATE_XXX

and thus deprecate MPI_TYPE_CONTIGUOUS and MPI_TYPE_VECTOR as well.
It could also be argued to have an MPI_TYPE_CREATE_HINDEXED_BLOCK as
counterpart to MPI_TYPE_CREATE_INDEXED_BLOCK (but I am not making a
strong suggestion).

best regards

Jesper

Chapter 4:
----------

Page 37, line 44-46:
(suggestion) drop, since this is largely a repetition of lines 34-36
(except the statement "It is not suggested that this be the only way..."

Page 43, line 34:
(suggestion) replace "may have only one value" by "can have only one value"

Page 43, line 34:
(suggestion) change "It consists of (key,value) pairs" to
"It stores a(n unordered) set of (key,value) pairs" to emphasize that the
info object is a kind of dictionary (data structure)

Page 43, line 37: 

(addition) "An empty info object is denoted by MPI_INFO_NULL."
(comment/discussion) The default is that the "null handle" is not
allowed as an IN argument (see MPI 1, Page 8, line 28), unless
explicitly allowed.  This explicit permission is missing at some
places in MPI-2 (I found two): MPI_WIN_CREATE, page 111, and 
MPI_FILE_SET_INFO, page 218. Is this default interpretation also intended
for MPI_INFO_NULL? A sentence on this would be in order, since the
info object is introduced here:" It is erroneous to pass MPI_INFO_NULL
as an IN argument, unless where explicitly allowed" (or whatever appropriate
depending on the intended interpretation).

Page 47, line 1:
(suggestion) change "Keys are numbered..." to
"At any point in time, keys are numbered consecutively from 0 to N-1, where..."

Page 47, line 32:
(addition)
"Advice to implementers: The info object is a dictionary, and can be
implemented by a suitable data structure. Since the number of (key,value) 
pairs can normally be assumed to be small a linear list implementation
will often suffice."

Page 49, line 21:
(addition) to align with the Fortran example 4.7, add C comment
"/* no memory is allocated */"

Page 49, line 22:
(addition) to make consistent with Fortran example, add line:
/* memory allocated */

Page 50, line 9:
(type) remove first "in"

Page 55, line 26: 
(comment) is this good Fortran style - scalars, e.g. 5 and MPI_REAL,
as implicit arrays of size 1? For a C programmer this is hurtful, and
some Fortran compilers do complain. I would suggest declaring the
proper arrays, so as to make the example more readily understandable, 
also to the Fortran non-expert. Same goes for the similar Example 4.14 
on Page 60.

Page 56, line 29:
(typo) "assciated" should be "associated"

Page 67, line 18:
(suggestion) change "array of integer" to "array of nonnegative integer"
(shouldn't it be "integers"?) - to make consistent with HVECTOR and
HINDEXED. 
(comment) There was an email discussion about 0-blocklengths, and
although it did not go very far, I think the conclusion was that
0-blocklengths are allowed and give rise to no element in the type
map. I think that some changes in the MPI-1 rules for how type maps
are generated by the INDEXED and STRUCT constructors are needed to
make this precise and correct.

Page 70-77:
(comment) Two pictures illustrating the subarray and distributed array 
constructors would be really helpful.

Page 74, line 9:
(typo) "is" missing in "it erroneous"

Chapter 5: 
----------

Page 85, line 25:
(typo) "as the as the" should be "as the"