[mpiwg-tools] proposed text

Wed Nov 19 10:38:14 CST 2014

Hi Marc-Andre,

>
>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.

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.

Kathryn

>
>Cheers,
>Marc-Andre
>
>PS: I know (almost) everyone is at SC, but maybe we can find a time for
>a call.

>
>On 18.11.14 22:03, Kathryn Mohror wrote:
>> I see what you mean, and that helps.
>> 
>> Do you think then, that all instances of the word "string" in this
>>chapter
>> (or the tools information interface part of the chapter anyway) need to
>>be
>> changed to "<foo> string"?
>> 
>> Or can we just say that we refer to them as <foo> strings wherever
>> confusion might arise? (That seems a bit dangerous, I think, because who
>> knows where confusion could arise for a particular reader?)
>> 
>> Kathryn
>> _________________________________________________________________
>> Kathryn Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore,
>>CA,
>> USA
>> 
>> 
>> 
>> 
>> 
>> 
>> On 11/18/14, 12:41 PM, "Marc-Andre Hermanns" <m.a.hermanns at grs-sim.de>
>> wrote:
>> 
>>> Hi Kathryn,
>>>
>>> if I understood right its a bit of both. We want to indicate that "our"
>>> strings (or their handling) are different from the rest of the
>>>standard,
>>> hence "MPI_T string" would be a good start. However, as I understand
>>> Jeff, it implies that "this is how MPI_T handles strings everywhere"
>>>and
>>> if we need some other handling of strings in MPI_T, we are then stuck
>>> with a name that implies the full scope of MPI_T when it does not
>>> provide it.
>>>
>>> What about "quasi-identical" strings to explicitly name what we want to
>>> express. Something along the lines of:
>>>
>>> Quasi-identical strings in MPI_T are strings that behave as if they are
>>> generated by a prefix-copy operation from a common source up to the
>>> length provided locally to the call returning the string.
>>>
>>> With something like this, we could then say, "foo" is a quasi-identical
>>> strings as discussed in 14.3.3, wherever we need it, e.g., for name and
>>> desc in the respective calls.
>>>
>>> What do you think?
>>>
>>> Cheers,
>>> Marc-Andre
>>>
>>> On 18.11.14 21:25, Kathryn Mohror wrote:
>>>> I'm a bit lost on the intended meaning behind the name: <foo> strings.
>>>>
>>>> Do you want <foo> strings to indicate all strings in the MPI tool
>>>> information interface that are by our definition in 14.3.3 treated
>>>> differently than in the rest of the standard? And then have a concept
>>>>of
>>>> identical <foo> strings and specify what is returned in the user's
>>>> buffer
>>>> for identical <foo> strings?
>>>>
>>>>
>>>> Or is <foo> strings supposed to only indicate strings that if
>>>>identical,
>>>> have a particular defined behavior that determine what is returned
>>>>into
>>>> the user's buffer according to our string conventions in 14.3.3?
>>>>
>>>> Thanks,
>>>> Kathryn
>>>>
>>>>>>> - so up in 14.3.3, have a definition for "<foo> strings" (someone
>>>>>>> come
>>>>>>> up
>>>>>>> with a better name than "<foo>"):
>>>>>>
>>>>>> MPI_T strings?
>>>>>
>>>>> Mmm.  That would imply that these are the *only* type of strings that
>>>>> are
>>>>> used in MPI_T.  That may be true today, but I don't know if we want
>>>>>to
>>>>> be
>>>>> locked in to that generalization for forever.
>>>>>
>>>>> How about "MPI_T universal strings"?
>>>>>
>>>>> -- 
>>>>> Jeff Squyres
>>>>> jsquyres at cisco.com
>>>>> For corporate legal information go to:
>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>> 
>> 
>> _______________________________________________
>> 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
>