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