[MPI3 Fortran] WG mission statement / bullets

[Jeff Squyres]

See the notice here:

     https://svn.mpi-forum.org/trac/mpi-forum-web/wiki



On Sep 3, 2009, at 9:17 AM, Malcolm Cohen wrote:

> BTW, my web browser complains about the security certificate on the  
> referenced
> web page.
>
> (この Web サイトで提示されたセキュリティ証明書 
> は、信頼された証明機関から発行されたものではあ 
> りません。)
>
> Steve Lionel wrote:
> > Hubert Ritzdorf wrote:
> >
> >> I think that the Fortran Programmers expect that these  
> definitions are made
> >> in Fortran integers and not in C_INT's.
> >> They want to use Fortran and not C and they want that the Fortran  
> compiler
> >> features are supported (such as expansion > of integers, reals  
> and double
> >> precisions).
> >
> > Fortran programmers would be using Fortran integers.  The KIND  
> value just
> > makes sure that they're the right kind of Fortran integers.  I am  
> not asking
> > Fortran programmers to code in C and the fact that C_INT is used  
> would be
> > invisible.  This is just a standard-conforming way of saying "give  
> me this
> > platform's default integer kind".
>
> Well, actually, "give me the kind that matches this platform's C  
> ``int''."
>
> As you wrote in another message, Fortran's default integer is not  
> always 32-bit.
>
> > Using generics, it's possible to define a routine that accepts  
> different
> > signatures, if that seems appropriate.  But the need for kind  
> values remains.
>
> I'd prefer us to provide generics (and not specifics) with the  
> generics taking
> both 32-bit and 64-bit integer for the "default" integer arguments.
>
> Craig Rasmussen wrote:
> > I've been back and forth on this (as well as a few others I think).
> > I'm currently leaning toward using default integers.
>
> Well, that's just MPI_INT_KIND=KIND(0).  It doesn't mean it should  
> not be
> documented if we are going to have specifics (which I obviously  
> don't favour).
> If we have specifics and not generics we absolutely want  
> MPI_INT_KIND so people
> can write stuff that works with and without -double.  And we surely  
> need
> MPI_SIZE_KIND for buffer sizes in any case, right?
>
> - - - - A couple of random comments...
>
> I don't understand how or why we are ruling out optional arguments  
> when there
> are optional arguments in the interface examples further down the  
> page.
>
> I also don't understand
>   "A discussion occurred at the April 2009 meeting about module use:  
> should the
> module name be MPI3 or just MPI as it is now. Decision is to that  
> the module
> name should be MPI to allow for continuity of users code. It is a  
> quality of
> implementation issue of just what is in the module. "
> ...?  I thought things were being changed, so how is this continuity  
> preserved?
> I mean, if we are switching from magic integers to
> handles/opaque-type-constants, that's going to change the interface,  
> right?  Or
> is the user going to write MPI3_Recv instead of MPI_Recv (i.e. the  
> "3" is on
> every call)?
>
> Cheers,
> --
> ......................Malcolm Cohen, Nihon NAG, Tokyo.
>
>
>
> _______________________________________________
> mpi3-fortran mailing list
> mpi3-fortran at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
>


-- 
Jeff Squyres
jsquyres at cisco.com