[mpiwg-tools] proposed text

[Marc-Andre Hermanns]

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

-------------- 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/20141119/61633339/attachment-0001.bin>