[mpiwg-tools] proposed text

[Kathryn Mohror]

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

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