[mpiwg-tools] proposed text

[Bronis R. de Supinski]

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