[mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info?

Kathryn Mohror kathryn at llnl.gov
Fri Aug 15 10:45:17 CDT 2014


I suppose it doesn’t change semantics, but possibly implementation of
tools and MPI libraries. I was under the impression that anything that
could change how a program that uses MPI is written couldn’t be ticket 0.

For my part, I don’t really think it’s wrong to not use the same
convention as the rest of the MPI library for true and false. We don’t use
the same string convention, after all.

Kathryn
_________________________________________________________________
Kathryn Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
Scalability Team @ Lawrence Livermore National Laboratory, Livermore, CA,
USA






On 8/14/14, 1:11 PM, "Jeff Squyres (jsquyres)" <jsquyres at cisco.com> wrote:

>How does it change semantics?
>
>On Aug 14, 2014, at 4:09 PM, Schulz, Martin <schulz6 at llnl.gov> wrote:
>
>> I would tend to agree with Kathryn, that this is more than ticket 0,
>>since it does change semantics. It seems to me, though, that this is a
>>clear bug in the specification and hence errata.
>> 
>> Martin
>> 
>> ________________________________________
>> From: mpiwg-tools [mpiwg-tools-bounces at lists.mpi-forum.org] on behalf
>>of Jeff Squyres (jsquyres) [jsquyres at cisco.com]
>> Sent: Thursday, August 14, 2014 12:07 PM
>> To: MPI Tool WG
>> Subject: Re: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info?
>> 
>> Is
>> 
>> s/0/false/g
>> s/1/true/g
>> 
>> (where relevant, of course)
>> 
>> in the Tools chapter more than a ticket-0 change?
>> 
>> 
>> On Aug 14, 2014, at 2:39 PM, Mohror, Kathryn <mohror1 at llnl.gov> wrote:
>> 
>>> Hi Jeff,
>>> 
>>> I see your point too. How do you propose to fix it? Make it clearer
>>>why we don't follow the same convention? Or change it to follow the
>>>rest of the standard? (The latter doesn't seem like ticket 0 to me.)
>>> 
>>> 
>>> 
>>> -- Kathryn
>>> 
>>> Sent with Good (www.good.com)
>>> 
>>> 
>>> -----Original Message-----
>>> From: Jeff Squyres (jsquyres) [jsquyres at cisco.com]
>>> Sent: Thursday, August 14, 2014 10:28 AM Pacific Standard Time
>>> To: MPI Tool WG
>>> Subject: Re: [mpiwg-tools] Too strict for flags in MPI_T_pvar_get_info?
>>> 
>>> I think the parts about the C convention/ignoring Fortran is fine.
>>> 
>>> But I think Junchao is raising the small-but-valid point that
>>>elsewhere in the doc, we say true/false for such things, but here in
>>>the tools chapter, we're saying 1/0.  So I'd say that this is a valid
>>>"consistency" kind of issue.
>>> 
>>> I'd further opine that this is a ticket 0 kind of change, and the
>>>chapter author should just make the change.
>>> 
>>> 
>>> 
>>> On Aug 14, 2014, at 1:19 PM, Kathryn Mohror <kathryn at llnl.gov> wrote:
>>> 
>>>> Hi Junchao,
>>>> 
>>>> Thanks as always for your sharp eyes. I think though in this case that
>>>> Nathan is correct. Since we only define a C interface for MPI_T and
>>>>try to
>>>> ignore Fortran altogether, it is okay to use the C convention for
>>>>true and
>>>> false.
>>>> 
>>>> Kathryn
>>>> _________________________________________________________________
>>>> Kathryn Mohror, kathryn at llnl.gov, http://scalability.llnl.gov/
>>>> Scalability Team @ Lawrence Livermore National Laboratory, Livermore,
>>>>CA,
>>>> USA
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 8/14/14, 9:49 AM, "Nathan Hjelm" <hjelmn at mac.com> wrote:
>>>> 
>>>>> 
>>>>> On Aug 14, 2014, at 10:35 AM, Junchao Zhang <jczhang at mcs.anl.gov>
>>>>>wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> It is a minor issue. In the Standard, the description for
>>>>> int MPI_T_pvar_get_info(..., int *readonly, int *continuous, int
>>>>> *atomic)
>>>>> says:
>>>>> Upon return, the argument readonly is set to zero if the variable can
>>>>> be written or reset by the user. It is set to
>>>>> one if the variable can only be read.
>>>>> (Same thing happens to continuous and atomic.)
>>>>> 
>>>>> 
>>>>> The description mandates an implementation must return 1 as TRUE,
>>>>>which
>>>>> does not follow C's convention. Other parts of MPI use true/false
>>>>>instead
>>>>> of 1/0 in description.  Section 2.6.3 make it clear that true means
>>>>> non-zero.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> How does that not follow C¹s convention? C mandates that the
>>>>>evaluation
>>>>> of a boolean operator (<, >, !, etc) MUST evaluate to either 0 or 1.
>>>>> Returning 0/1 here makes perfect sense.
>>>>> 
>>>>> 
>>>>> Other parts of MPI probably use true/false because fortran logicals
>>>>>do
>>>>> not use 0/1 for false/true.
>>>>> 
>>>>> 
>>>>> -Nathan Hjelm
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> mpiwg-tools mailing list
>>>> mpiwg-tools at lists.mpi-forum.org
>>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>>> 
>>> 
>>> --
>>> Jeff Squyres
>>> jsquyres at cisco.com
>>> For corporate legal information go to:
>>>http://www.cisco.com/web/about/doing_business/legal/cri/
>>> 
>>> _______________________________________________
>>> mpiwg-tools mailing list
>>> mpiwg-tools at lists.mpi-forum.org
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>>> 
>>> _______________________________________________
>>> mpiwg-tools mailing list
>>> mpiwg-tools at lists.mpi-forum.org
>>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>> 
>> 
>> --
>> Jeff Squyres
>> jsquyres at cisco.com
>> For corporate legal information go to:
>>http://www.cisco.com/web/about/doing_business/legal/cri/
>> 
>> _______________________________________________
>> mpiwg-tools mailing list
>> mpiwg-tools at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>> _______________________________________________
>> mpiwg-tools mailing list
>> mpiwg-tools at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools
>
>
>-- 
>Jeff Squyres
>jsquyres at cisco.com
>For corporate legal information go to:
>http://www.cisco.com/web/about/doing_business/legal/cri/
>
>_______________________________________________
>mpiwg-tools mailing list
>mpiwg-tools at lists.mpi-forum.org
>http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-tools





More information about the mpiwg-tools mailing list