[Mpi3-bwcompat] MPI_Count Ticket 265 feedback

[Solt, David George]

We have a call scheduled this Friday, but we can get things rolling via e-mail before then.

>> Page9_at_30: For backward compatibility, many MPI routines use int in C or INTEGER in Fortran as count arguments.

Hold on... looking for a 10 foot pole.... I'm not sure I like my own suggestion, but here it is:  "Most MPI routines use int in C or INTEGER in Fortran as count arguments rather than MPI_Count.  Routines use MPI_Count as the type for the count argument where they are deemed most likely to exceed the storage capacity of a int or INTEGER."

>> Page9_at_19: ...count values, and that type is MPI_Count...

This change makes no sense to me.   The very next sentence says, "The datatype of such an argument is MPI_Count...".   Does someone remember what this was about?

>> Page9_at_29: confusion about 'type map' applying to memory only, not file view

I don't remember the rationale for our rationale :).   It seems to say, "Count values need to be big enough to hold any count values".  Even if we changed it to "The storage used for storing MPI_Count values needs to be large enough to hold any count values" doesn't seem any more useful a statement.   Maybe this should be something of the form "Advice to Implementers:  The larger the storage use for MPI_Count, the larger the type maps an application can create for working with large files and message data. 

>> Page120_at_38: Use similar wording to previous "limits" wording might be better (more consistent)
>> Need to mention overflow for MPI_GET_COUNT?  One could use MPI_STATUS_SET_ELEMENTS_X to overflow MPI_GET_COUNT.

If the number of basic elements received exceeds the limits of the count parameter, then MPI_PACK_SIZE set the value of count to MPI_UNDEFINED.

For the MPI_GET_COUNT, it already says this:

"(We shall later see, in Section 4.1.11, that MPI_GET_COUNT
may return, in certain situations, the value MPI_UNDEFINED.)".   Does that cover it or should we replace it with:

If the number of basic elements received exceeds the limits of the count parameter, then MPI_GET_COUNT set the value of count to MPI_UNDEFINED.

I don't think we have to distinguish between "received" and "set by MPI_STATUS_SET_ELEMENTS[X], since this is intended to implement as generalized request receive which is still a form of a "receive".

Thoughts?
Dave 

-----Original Message-----
From: mpi3-bwcompat-bounces_at_[hidden] [mailto:mpi3-bwcompat-bounces_at_[hidden]] On Behalf Of Jeff Squyres
Sent: Monday, April 11, 2011 4:13 PM
To: MPI-3 backwards compatability WG
Subject: Re: [Mpi3-bwcompat] MPI_Count Ticket 265 feedback

On Apr 11, 2011, at 5:10 PM, Jeff Squyres wrote:

> Note that there is not much time before the next Forum meeting.
> 
> To get this in the pre-requisite 2 weeks before the Forum meeting, we have to send around a new document by *Monday, May 25*.  Or *exactly 2 weeks from today*.

Er... I meant *Monday, APRIL 25*.

:-)


-- 
Jeff Squyres
jsquyres_at_[hidden]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________
Mpi3-bwcompat mailing list
Mpi3-bwcompat_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-bwcompat