[mpiwg-tools] proposed text

[Kathryn Mohror]

The updated version is attached. Please comment if you have a chance so we
can get this done by Monday.

Thank you!
Kathryn
_________________________________________________________________
Kathryn Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA,
USA






On 11/21/14, 7:09 AM, "Kathryn Mohror" <kathryn at llnl.gov> wrote:

>Thanks for the feedback Michael and Marc-Andre! I'll make the changes
>later this morning and send them out.
>
>Kathryn
>_________________________________________________________________
>Kathryn Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
>Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA,
>USA
>
>
>
>
>
>
>On 11/21/14, 2:38 AM, "Marc-Andre Hermanns" <m.a.hermanns at grs-sim.de>
>wrote:
>
>>Hi all,
>>
>>> I have an issue with the new text. I'm not sure if I'm missing a
>>> point, but for me the equivalence text is redundant. I fail to see a
>>> difference between (page 9, lines 43ff)
>>> 
>>> Strings are equivalent if the MPI implementation behaves as if it has
>>> an identical character array in each MPI process for the string in
>>> question across connected processes. The contents of the returned
>>> string will be identical to that of the internal character array, but
>>> possibly truncated at any process that supplies an n value to the
>>> query routine that is smaller than the length of the internal
>>> character array.
>>
>>I also think this covers all cases.
>>
>>a) a string is equivalent to its internal "source" if it behaves as if
>>being copies from it up the the given length.
>>
>>b) two strings are equivalent when they behave as if the originate from
>>an identical source.
>>
>>> and (page 10, lines 1ff)
>>> 
>>> Two strings are equivalent if the internal character array for each
>>> MPI process is identical by a character-by-character comparison, and
>>> in the output buffer, any arbitrary combination of length arguments
>>> result in the same string-prefix up to the smaller of the two lengths.
>>> 
>>> So I'll probably would remove the second part (although I still like
>>> the wording).
>>> 
>>> Any opinions on that?
>>
>>I talked to Michael on this, and I also think the second part can be
>>omitted.
>>
>>> The rest looks fine so far.
>>
>>dito.
>>
>>Cheers,
>>Marc-Andre
>>-- 
>>Marc-Andre Hermanns
>>Jülich Aachen Research Alliance,
>>High Performance Computing (JARA-HPC)
>>German Research School for Simulation Sciences GmbH
>>
>>Schinkelstrasse 2
>>52062 Aachen
>>Germany
>>
>>Phone: +49 241 80 99753
>>Fax: +49 241 80 6 99753
>>www.grs-sim.de/parallel
>>email: m.a.hermanns at grs-sim.de
>>
>
>
>_______________________________________________
>mpiwg-tools mailing list
>mpiwg-tools at lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tools-3.pdf
Type: application/pdf
Size: 327819 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20141121/da7e7d25/attachment-0001.pdf>