<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Torsten,<br>
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:<br>
   
<a class="moz-txt-link-freetext" href="http://www.hlrs.de/organization/par/services/models/mpi/mpi21/doc/mpi-report.pdf">http://www.hlrs.de/organization/par/services/models/mpi/mpi21/doc/mpi-report.pdf</a><br>
-Adam<br>
<br>
Torsten Hoefler wrote:
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">Hi Rolf, Adam,
I understand from your mail Rolf, that Adam lost his write token and
that only you can apply the changes/comments to the chapter (in my case
the collectives chapter). Thus, I'll send my review results to the list
instead the chapter author directly. My general comment: very well done
Adam :).

I have some smaller editing remarks and also found some small errors and
clarification possibilities (see below).

  </pre>
  <blockquote type="cite">
    <pre wrap="">----------------------------------------------------------------------------------
1234567890123456789012345678901234567890123456789012345678901234567890123456789012
          All references are based on MPI-2.1 Draft Apr. 12, 2008
ww.a  __  pnnn.ll text   (with nnn=page number and ll=line number
          text continued
          ...
ww.b  __  pnnn.ll text ... and so on (total line length <= 82 characters.)
----------------------------------------------------------------------------------
    </pre>
  </blockquote>
  <pre wrap=""><!---->Ok, here my remarks, many of them (especially EDIT or CLAR) can probably
be ignored, but I thought I'd bring it up:

general: the line numbers are completely out of sync ... it's hard to
classify a line that is between two line numbers.

5.a DON2  EDIT p129.19-41 "all group members" vs. "all members of a group"
                    should use the same phrasing (parallel structure)
  </pre>
</blockquote>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">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"
  </pre>
</blockquote>
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:<br>
    "A collective operation is executed by having all processes in the
same group call the<br>
    communication routine, with matching arguments. One of the key
arguments is a communicator ..."<br>
are now written more simply as:<br>
    "One of the key arguments in a call to a collective routine is a
communicator ..."<br>
<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">5.f   vv  CLAR p131.1     add "with exceptions stated in the following" to first
                    sentence
  </pre>
</blockquote>
Do you mean exceptions to the matching of datatypes in sender and
receiver?  Are there exceptions to this?<br>
<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">5.g DON2  EDIT p131.4     no linebreak (Chapter~\ref{...})
5.h *NO*  ERR  p131.31    replace "will" with "might"
  </pre>
</blockquote>
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.<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">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)
  </pre>
</blockquote>
Could you specify the particular advice via page and line numbers? 
It's not clear to me what you are referring to here.<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">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)
  </pre>
</blockquote>
Do you mean p132.27 instead?  The recommendation doesn't seem to line
up with the document I have.<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">5.k *NO*  EDIT p133.32    "a" -> "an"?
  </pre>
</blockquote>
I think "a" is actually appropriate here.<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">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?)
  </pre>
</blockquote>
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.<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">5.o *NO*  EDIT p136.32    move sentence to end of the previous paragraph (line
                    25)
  </pre>
</blockquote>
Although, this text may read more smoothly with this edit, it breaks
symmetry on where the "in place" statements are placed in other
descriptions.<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">5.p *NO*  EDIT p136.37    "data is braodcasted" (not braodcast)
  </pre>
</blockquote>
Left as "broadcast" per discussion between Bronis and Torsten which
concluded that "broadcast" is recommended.<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">5.q DON2  CLAR p136.38-39 the text talks about send and receive buffer argument,
                    but bcast only has a single buffer argument ...
  </pre>
</blockquote>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">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)
  </pre>
</blockquote>
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.<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">5.s DON2  EDIT p138.3     write "all processes" instead of "process i" (i is
                    never defined)
  </pre>
</blockquote>
I changed this to:<br>
    "The type signature of sendcount, sendtype on each process must be
equal ..."<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">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?)?
  </pre>
</blockquote>
I think the "that is, ..." portion of this statement clarifies the
meaning.<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">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)
  </pre>
</blockquote>
Again, I'll leave this redundancy question to the Forum.<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">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)
  </pre>
</blockquote>
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.<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">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)
  </pre>
</blockquote>
I don't see examples in this chapter that say they are in C either, or
at least, there are many that don't.<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">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.
  </pre>
</blockquote>
Ok, I've been convinced to remove this.<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">5.ab DON2  CLAR p163.20    replace "bit" by "numeric" or "integer"
5.ac *NO*  EDIT p167.41    doubled sentence "The order of ..."
  </pre>
</blockquote>
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.<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">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
  </pre>
</blockquote>
Again, not sure if this needs to be done?<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">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)
  </pre>
</blockquote>
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.<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">5.ak   ?? CLAR p179.27    maybe we should add: "and to ensure appropriate
                     matching (for deterministic behavior)
  </pre>
</blockquote>
I'll leave this one to the Forum.<br>
<blockquote cite="mid20080413183551.GS9521@benten.cs.indiana.edu"
 type="cite">
  <pre wrap="">
Best,
  Torsten

  </pre>
</blockquote>
</body>
</html>