[Mpi-21] AUTHORS+REVIEWERS - Draft Apr. 12, 2008

[Torsten Hoefler]

Hi Adam, Rolf,
> I've marked most of your edits with DON2, which means I've made the 
> change as you recommended.  However, there are a number for which I'm 
> not clear on what you meant.  These are marked with "vv", which points 
> to the question following.  Would you please clarify these items?  As a 
> reference, let's use the following document for page and line numbers:
>     
> http://www.hlrs.de/organization/par/services/models/mpi/mpi21/doc/mpi-report.pdf
> -Adam
Thanks Adam! I commented on your comments below. Ah, btw. the page
numbers are *not* correct in xpdf (pdf page numbers vs. printed page
numbers).

Rolf, please add the things we decided to run by the Forum to some
ballot for the meeting next week - they should be easy to solve. Thanks!

> >general: the line numbers are completely out of sync ... it's hard to
> >classify a line that is between two line numbers.
This is still ambiguous, but it seems to be a general problem. Why is
the font used to number the lines smaller than the text in the lines?

> >5.a DON2  EDIT p129.19-41 "all group members" vs. "all members of a group"
> >                    should use the same phrasing (parallel structure)
> >  
> >
> >5.b DON2  NICE p129.41    Reference to 5.11 not 5.11.1
> >5.c DON2  EDIT p129.45    remove "," (comma)
> >5.d DON2  EDIT p129.43    replace "the same" with "a"
> >5.e DON2  EDIT p129.45    "the same group" in line 43 conflicts with "group or
> >                    groups"
> >  
> >
> There is not really a clear way to state this.  As Rejeev also 
> suggested, the definition of "matching" is not well understood here.  
> Perhaps the best option is to remove this statement altogether, since it 
> is defined in more detail in the "Specifics" sections for intra- and 
> inter-communicators.  I'll remove the statement, but the idea of 
> "matching" parameters in collective calls should be discussed in the 
> Forum.  Thus, the following lines:
>     "A collective operation is executed by having all processes in the 
> same group call the
>     communication routine, with matching arguments. One of the key 
> arguments is a communicator ..."
> are now written more simply as:
>     "One of the key arguments in a call to a collective routine is a 
> communicator ..."
ok

> >5.f   vv  CLAR p131.1     add "with exceptions stated in the following" to first
> >                    sentence
> >  
> >
> Do you mean exceptions to the matching of datatypes in sender and 
> receiver?  Are there exceptions to this?
The expection is for arguments that are only significant at certain
processes. I.e., not all arguments must match (because they are
ignored). But I guess it's ok and clear as it is - we don't need a
change here.

> >5.g DON2  EDIT p131.4     no linebreak (Chapter~\ref{...})
> >5.h *NO*  ERR  p131.31    replace "will" with "might"
> >  
> >
> I'd leave this in, since it was the original wording for this version of 
> the standard.  I think there is still an escape here already in the "(or 
> a similar mechanism)" phrase.
I would like to run this by the Forum. Yes, it is the original wording,
but some parts of the original wording are not accurate, so we should
discuss this. Non-blocking collectives without tags are possible and
useful, so why should we say wrong things in the revised version of the
standard? And we also do not need "similar mechanisms". I'd say this
sentence is misleading.

> >5.i   vv  ERR  p132.      "special communicator must be created" this is wrong,
> >                    later (in the bcast section) it is stated differently 
> >                    ... I would just remove this part of the advice or say
> >                    "might be created" (see Bcast advice)
> >  
> >
> Could you specify the particular advice via page and line numbers?  It's 
> not clear to me what you are referring to here.
ups, I forgot the line numbers here - sorry! It's line 1-2. It says that
implementors need to implement a "special communicator". Nobody does
this, most implementations just use special tags. So this advice is also
misleading (actually wrong).

> >5.j   vv CLAR p131.37    add "depending on the operation performed after last
> >                    sentence (right now it sounds like ths user is free to
> >                    choose which argument to replace)
> >  
> >
> Do you mean p132.27 instead?  The recommendation doesn't seem to line up 
> with the document I have.
yes, this is line 27, got confused with the line numbers here.

> >5.k *NO*  EDIT p133.32    "a" -> "an"?
> >  
> >
> I think "a" is actually appropriate here.
hmm, I learned that "an" has to come before words starting with a,e,o,u
... but "a" sounds (flows) much more natural. Don't change it (that's
why I added the "?" to my original comment :).

> >5.l DON2  EDIT p136.22    start sentence with "If the communicator is an
> >                    intracommunicator" as for all the other operations,
> >                    remove "for intracommunicators" in line 23
> >5.m DON2  EDIT p136.24    replace "," by "and"
> >5.n   ??  EDIT p136.26-31 this paragraph is redundant (it's all already stated
> >                    earlier, do we want this redundancy in the standard?)
> >  
> >
> I agree that it is redundant, but this emphasis in a particular case may 
> be useful to get the point across.  I'd leave it up to the Forum to vote 
> on this.
ok, good idea.

> >5.o *NO*  EDIT p136.32    move sentence to end of the previous paragraph (line
> >                    25)
> >  
> >
> Although, this text may read more smoothly with this edit, it breaks 
> symmetry on where the "in place" statements are placed in other 
> descriptions.
ok, I agree.

> >5.p *NO*  EDIT p136.37    "data is braodcasted" (not braodcast)
> >  
> >
> Left as "broadcast" per discussion between Bronis and Torsten which 
> concluded that "broadcast" is recommended.
yes!

> >5.q DON2  CLAR p136.38-39 the text talks about send and receive buffer argument,
> >                    but bcast only has a single buffer argument ...
> >  
> >
> >5.r   ??  CLAR p136.38    "must be consistent with the ..." what does the word
> >                    consistent mean in this context? This seems undefined.
> >                    I think it means that the signature (size, count) is
> >                    the same. We should say this explicitely. The same
> >                    term "consistent" is used in all following operations
> >                    (I'm not going to add it again)
> >  
> >
> I agree that "consistent" is not defined, however, I'm not sure what it 
> means either.  I think this change should be left to the Forum.
Yes, I'd just say that this needs to be defined. I can only guess what
it means.

> >5.s DON2  EDIT p138.3     write "all processes" instead of "process i" (i is
> >                    never defined)
> >  
> >
> I changed this to:
>     "The type signature of sendcount, sendtype on each process must be 
> equal ..."
perfect!

> >5.t *NO*  ERR p139.47     data is not necessarily placed in rank order. The
> >                    order is freely definably by the user in the displs[]
> >                    array. Or does the standard enforce the displs[] array
> >                    to preserve order? We might want to run this through
> >                    the forum (or just ignore it?)?
> >  
> >
> I think the "that is, ..." portion of this statement clarifies the meaning.
I don't think so. I also discussed this with Jesper who also thinks that
this is a controversary statement. Actually, I'd say that the standard
forces the displs[] array to be in rank-order. Everything else can be
interpreted as an erroneous MPI program. I think we don't want this. But
we should run this by the Forum.

> >5.u DON2  CLAR p136.42    add "The examples in this section are using
> >                    intracommunicators." as in p140.27
> >5.v   ??  EDIT p147.48    the last paragraph is redundant (has been stated
> >                    before for all collectives)
> >  
> >
> Again, I'll leave this redundancy question to the Forum.
ok

> >5.w DON2  EDIT p157.35    why a separate subsection for Alltoallw but not for
> >                    Alltoallv? I'd remove this subsection
> >5.x DON2  EDIT p157.36    the first two sentences should go to rationale (we
> >                    don't need to rationalize the operation in the
> >                    description)
> >  
> >
> I missed this piece in the original rewrite, and so this section still 
> required significant editting.  I've made it look and feel more like the 
> AlltoallV definition.
great!

> >5.y DON2  EDIT p161.13    replace "Reduce" by "Reduction" or "Operations for
> >                    MPI_Reduce"
> >5.z   vv  EDIT p162.13    state that the example is in Fortran (it's said for
> >                    all the C examples before)
> >  
> >
> I don't see examples in this chapter that say they are in C either, or 
> at least, there are many that don't.
ok, there are some that do and some that don't. Ah, I don't care ...
people who are not able to recognize the language are not our target
audience anyway (I hope).

> >5.aa DON2  EDIT p163.10-12 I think we don't need to backref to MPI-1 here if we
> >                     consider MPI-2.1 a complete standard.
> >  
> >
> Ok, I've been convinced to remove this.
:)

> >5.ab DON2  CLAR p163.20    replace "bit" by "numeric" or "integer"
> >5.ac *NO*  EDIT p167.41    doubled sentence "The order of ..."
> >  
> >
> The sentence is not technically duplicated.  I'll leave this text as is 
> now, although, I agree that this paragraph could be rewritten to state 
> its point more clearly.
"The order of evaluation can be changed, talking advantage of the
associativity of the operation. If commute = true then the order of
evaluation can be changed" ... ok, I see. It sounds like double. I'd
still re-phrase this into a single sentence, such as: "If commute =
true, then the order of evaluation can be changed, talking advantage of
the associativity of the operation."

> >5.ad DON2  CLAR p169.2     add: (without supporting the "in place" option)
> >5.ae DON2  ERR  p169.16-20 the example will deadlock if root == groupsize-1. Has
> >                     been there for a while :). Use Irecv/Wait instead.
> >5.af   vv  EDIT p171.48    state that example is in Fortran
> >  
> >
> Again, not sure if this needs to be done?
agree - please ignore this

> >5.ag DON2  ERR  p174.12-20 this rationale should be erased completely because it
> >                     explains (for MPI-1), why only the inclusive is supported ;-)
> >5.ah DON2  ERR  p175.20    erase the last sentence in rationale, we don't need
> >                     this anymore (is MPI-1)
> >5.ai   ??  EDIT p177.48    move orphaned Example header to next page (might
> >                     change after edits though -> check chapter for orphans)
> >5.aj   ?? EDIT p179.24    the font suddenly changes? (sans-serif)
> >  
> >
> Haven't checked these two in the recent document.  I suppose some of the 
> checks will need to wait until the final copy is available for reading.
yes, I just wanted to remind us to do it at the end.

> >5.ak   ?? CLAR p179.27    maybe we should add: "and to ensure appropriate
> >                     matching (for deterministic behavior)
> >  
> >
> I'll leave this one to the Forum.
ok

Thanks & Best,
    Torsten


-- 
 bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ -----
Indiana University    | http://www.indiana.edu
Open Systems Lab      | http://osl.iu.edu/
150 S. Woodlawn Ave.  | Bloomington, IN, 474045-7104 | USA
Lindley Hall Room 135 | +01 (812) 855-3608