[mpiwg-tools] proposed text

Thu Nov 20 13:58:37 CST 2014

Hi all,

Here's the latest text based on the conversation during the impromptu
meeting Marc-Andre, Michael and I had this morning.

JEFF: The question of whether we want to include enumerations in the
requirements for equivalency. I know you had an argument against this at
some point, but I can't find it in my notes. Thus, in the attached
document, I put a place holder where we might want to consider adding
enumerations marked with "JEFF".

- We worked out the text such that we don't need to name strings (as in
<foo> strings), but simply refer to the concept of strings being
equivalent.
- This simplified the text that needed to go in the *_get_info routines.

Marc-Andre and Michael, please let me know if I missed any of your points!

All: for the {pvar,cvar}_get_index routines, do we need to be more
specific about what the contents of 'name' are and what 'matches' means
given the text we have added for 383?

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

On 11/20/14, 6:00 AM, "Marc-Andre Hermanns" <m.a.hermanns at grs-sim.de>
wrote:

>Hi Kathryn,
>
>you used the <foo>=MPI_T version right?
>
>What do you think about this:
>
>---o---o---o---o---
>14.3.3
>
>...
>Several query functions of the MPI_T interface return information
>encoded in C strings. A user of these query routines can influence the
>concrete length of the output through INOUT length parameters to these
>calls, potentially resulting in a truncated string. As the INOUT length
>parameters are allowed to vary across different invocations of a call,
>two strings returned by subsequent calls with varying length arguments
>but otherwise identical arguments may not be identical as defined by the
>result of the strcmp family of calls. However, they have to be
>equivalent. In the scope of the MPI_T interface, two strings are
>regarded equivalent, if any arbitrary combination of length arguments
>result in the same string-prefix up to the smaller of the two lengths.
>
>---o---o---o---o---
>
>This goes back to Michael's initial idea of regarding "pairs of
>strings". Again, some of my prose may be convoluted and I am open to any
>revision. ;-)
>
>And then we don't need the "MPI_T" string at all, as the equivalence is
>all the "specialness" we want from our strings. Thus, we can then (at
>those 6 places) just state: "parameters foo and bar have to be
>equivalent as described in 14.3.3."
>
>What do you think?
>
>Cheers,
>Marc-Andre
>
>
>On 19.11.14 21:53, Kathryn Mohror wrote:
>> Okay, here's a draft attempting to capture what Jeff and Martin were
>> getting at in the last meeting. I made changes to 14.3.3 and to the text
>> of the get_info routines for name and desc parameters, and to the last
>> paragraph for the routine description.
>> 
>> Have at it!
>> 
>> Kathryn
>> _________________________________________________________________
>> Kathryn Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore,
>>CA,
>> USA
>> 
>> 
>> 
>> 
>> 
>> 
>> On 11/19/14, 12:17 PM, "Kathryn Mohror" <kathryn at llnl.gov> wrote:
>> 
>>> Thanks Bronis. I like the suggestion of equivalence instead of
>>>identical.
>>>
>>> Kathryn
>>>
>>>
>>>>
>>>> "quasi-identical" and its variants sounds horrible to
>>>> me without even looking at the context. What do you
>>>> want to require? "functionally equivalent"? I think
>>>> you need to move away from the word "identical" and
>>>> think instead in terms of "equivalence"...
>>>>
>>>> On Wed, 19 Nov 2014, Marc-Andre Hermanns wrote:
>>>>
>>>>> Hi Kathryn,
>>>>>
>>>>>>> I think we don't have to search&replace the word string for <foo>
>>>>>>> string
>>>>>>> throughout the chapter. I think we only need to define <foo> string
>>>>>>> in
>>>>>>> 14.3.3 and then state for the 6 parameters so far that those are
>>>>>>>foo
>>>>>>> strings.
>>>>>>
>>>>>> Okay, I'll work on it and try to integrate it cleanly.
>>>>>>>
>>>>>>> By and large <foo> strings are just like other C string. We just
>>>>>>>have
>>>>>>> additional requirements to what "identical" means. That is why I
>>>>>>>came
>>>>>>> up
>>>>>>> with the name: "quasi-identical", because they are not identical in
>>>>>>> the
>>>>>>> normal C string sense (str*cmp). As "quasi-identical" is a new kind
>>>>>>> of
>>>>>>> string, that probably no-one heard in a different context, so has
>>>>>>>no
>>>>>>> preoccupation on what it could mean, a reader should go: "What's
>>>>>>> that?"
>>>>>>> and refer to Section 14.3.3.
>>>>>>>
>>>>>>> What's the groups take on the name "quasi-identical"?
>>>>>>
>>>>>> I'm not totally sold on 'quasi-identical' but possibly because I
>>>>>>don't
>>>>>> use
>>>>>> the prefix 'quasi' very often. Also, I almost think that it takes
>>>>>>away
>>>>>> from the fact that the internal representation of the strings does
>>>>>> need to
>>>>>> be identical, but what is passed to the user may be different due to
>>>>>> truncation.
>>>>>
>>>>> Yes, the "quasi" might be a German thing, although I think is also
>>>>> exists in English. I am open to any other suggestion.
>>>>>
>>>>> For the the quasi just expresses their actual state, we regard them
>>>>>as
>>>>> identical, although the actual strings returned do not have to the
>>>>> identical in the strcmp sense (due to different length). So they are
>>>>> identical and at the same time they are not. That is a little "quasi"
>>>>> to
>>>>> me ;-)
>>>>>
>>>>> What about:
>>>>>
>>>>> prospect-identical?
>>>>> source-identical?
>>>>>
>>>>>> That said, I don't have a replacement suggestion right this second.
>>>>>
>>>>>>> Should we have an "out-of-order" telco tomorrow to discuss this? As
>>>>>>> we
>>>>>>> need to finalize our wording by Monday in order for 383 to be an
>>>>>>> errata,
>>>>>>> I think we need to make progress before the weekend.
>>>>>>
>>>>>> I'm not sure if that will work with everyone at SC. It would
>>>>>>coincide
>>>>>> with
>>>>>> the 10:00 AM technical papers sessions. I suppose though if people
>>>>>> pipe up
>>>>>> that they would be able to join, that would be good and I would be
>>>>>> able to
>>>>>> be on the call. Of course, as you say in your post script, we could
>>>>>> pick
>>>>>> another time, too.
>>>>>
>>>>> Obviously, I am fine with any earlier time slot, but that would not
>>>>>go
>>>>> well with pacific time. I would have more again after 8 pm CET. Maybe
>>>>> the people at SC suggest a time that fits into the program for them?
>>>>>
>>>>> 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
>> 
>> 
>> 
>> _______________________________________________
>> mpiwg-tools mailing list
>> mpiwg-tools at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>> 
>
>-- 
>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
>

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