[mpiwg-tools] proposed text

[Marc-Andre Hermanns]

Hi Bronis,

thanks for the input on this. I also like the "equivalency" better than
my earlier suggestions.

Cheers,
Marc-Andre

On 19.11.14 21:02, Bronis R. de Supinski wrote:
> 
> "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
> 

-- 
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: smime.p7s
Type: application/pkcs7-signature
Size: 4842 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20141120/0a136076/attachment-0001.bin>