[mpiwg-tools] proposed text

[Kathryn Mohror]

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