[mpiwg-tools] proposed text
m.a.hermanns at grs-sim.de
Thu Nov 20 06:59:35 CST 2014
thanks for the input on this. I also like the "equivalency" better than
my earlier suggestions.
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>
>>>> 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
>>> 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
>> 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:
>>> 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
>>>> 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
>>> 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?
>> Marc-Andre Hermanns
>> Jülich Aachen Research Alliance,
>> High Performance Computing (JARA-HPC)
>> German Research School for Simulation Sciences GmbH
>> Schinkelstrasse 2
>> 52062 Aachen
>> Phone: +49 241 80 99753
>> Fax: +49 241 80 6 99753
>> email: m.a.hermanns at grs-sim.de
> mpiwg-tools mailing list
> mpiwg-tools at lists.mpi-forum.org
Jülich Aachen Research Alliance,
High Performance Computing (JARA-HPC)
German Research School for Simulation Sciences GmbH
Phone: +49 241 80 99753
Fax: +49 241 80 6 99753
email: m.a.hermanns at grs-sim.de
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4842 bytes
Desc: S/MIME Cryptographic Signature
More information about the mpiwg-tools