Yes, this is the intent. The reason is that while
"double precision" exists in F90, it is not the preferred
way to declare things. What is "double precision" in f77
should probably be declared using "real" in f90.
So it made sense to make 8 bytes the default (and of course
it is not difficult to change, but the default should be the
common case).
We did vote last time to give MPI_REAL an external rep of
4 bytes, but my suggestion would be to reconsider in light
of the full F90 picture. What do you think?
> b) Does I understand right, that
>
> real(selected_real_kind(25, 0)) q
> MPI_TYPE_CREATE_F90(MPI_REAL, kind(q), XTYPE, ierr)
>
> will have q with 16 bytes and XTYPE therefore representing
> a type identical to MPI_REAL16 for internal usage,
> but with only 8 byte external representation?
Yes.
>
> If yes, then I believe that this is no real problem, but we
> should add an Advice to users with a WARNING and an advice
> to use MPI_TYPE_CREATE_EXTERNAL for that case.
Good idea.
> > 2. Add a new function
> >
> > MPI_TYPE_CREATE_EXTERNAL(IN basictype, IN size, OUT newtype)
> >
> > basictype is one the basic integer or floating point types
> > (MPI_INTEGER, MPI_REAL, or a type returned by MPI_TYPE_CREATE_F90 from
> > one of these basetypes). This can easily be extended to C to include
> > MPI_INT, MPI_FLOAT, MPI_DOUBLE, etc. ).
>
> c) I believe this should be extended to C because this allows to
> overwrite the external size.
> And it should also be extended to optional types and logical types,
> i.e. all numerical types ('numerical' in the sense of Fortran)
I see no problem extending to all real/integer types. I didn't
say anything for logical data because the current external
format specification only lists one type of logical. We could
extend that.
>
> > Size is either 4 or 8, corresponding to one of the prefedined
> > representations.
>
> d) We should also allow 16 for floating point types to give a
> solution for the requirement to exchange LONG_DOUBLE and
> DOUBLE_PRECISION between 64-bit systems.
>
Not a bad idea. Again, I didn't include this because we do not
already have a type defined. (Or do we?)
Is there a standard 16-byte IEEE format?
Bill