[MPI3 Fortran] Straw vote on integers kinds

[Malcolm Cohen]

Craig Rasmussen wrote:
> Please vote for one of the options.

I don't see the option I prefer, viz all interfaces to be generic and not 
specific.  Furthermore, that MPI_INT_KIND and default integer are both supported 
(if different).  I guess option 4 might come closest to allowing the vendor to 
do that, but it's better if they are already generic to start with.

> However, I also think the standard should also leave room for
> vendors to provide additional integer kinds via generics or
> separate compilation libraries

If MPI says they are (specific) procedures, then that does make a limitation.

Why would anyone want to pass one of these as an actual argument anyway?  That's 
the only "benefit" from them being specific procedures.

Bill Long wrote:
> Of course, the ideal situation would be to outlaw completely the use of 
> the -i8 and -r8  (and even worse, one and not the other) options.
> Perhaps this could be an MPI requirement - no program that uses MPI is allowed 
> to use these switches.  That would be an enormous step in the right direction.

Use of -i8 without -r8 and vice versa are already prohibited by the Fortran 
standard, where it says that default integer and default real take the same 
storage size.  I don't see what saying it again in MPI gains you.

Another thread:
>>> The only C double that is passed in the MPI interface is the return value 
>>> from MPI_WTICK and MPI_WTIME.
>>>
>>
>> So let's get rid of MPI_DOUBLE_KIND.  The compiler will do normal type 
>> conversion for return values so we don't really have the same issue we have 
>> with procedure arguments.
>>
>> But what is the correct way to specify the result value?  I believe DOUBLE 
>> PRECISION is frowned upon.  I haven't been on the committee long enough to 
>> know the reason.
>
>DOUBLE PRECISION is problematic, since the dreaded -r8 switch may turn this 
>into a 128-bit floating point value.

Or the compiler might naturally consider REAL to be 64-bit and DOUBLE PRECISION 
to be 128-bit.  The existence of such compilers is the basis for the existing 
of -r8/-i8/-double in other compilers the first place.

So,
>> DOUBLE PRECISION is frowned upon.  I haven't been on the committee long 
>> enough to know the reason.

quite simply DOUBLE PRECISION just means twice the storage, and some more 
precision, than default real.  That's all it means.  32/64, 36/72, 48/96, 60/120 
and 64/128 have all been "popular" size pairs for default real and double 
precision (without any special compiler options).

MPI could pick REAL(C_DOUBLE from ISO_C_BINDING) as Bill suggested, though 
C_DOUBLE is not guaranteed to be available, or REAL(REAL64 from 
ISO_FORTRAN_ENV), which is more likely to be available but not necessarily, or 
REAL(SELECTED_REAL_KIND(12)) if what is actually wanted is 12 decimal digits of 
precision - virtually certain to be available, or REAL(MPI_WTIME_KIND) which 
actually is certain to be available.

Furthermore,
>> So let's get rid of MPI_DOUBLE_KIND.  The compiler will do normal type 
>> conversion for return values so we don't really have the same issue we have 
>> with procedure arguments.

So when the user wants to declare a variable to hold one of these, your 
suggestion is that he do
    REAL(KIND(MPI_WTIME(whatever arguments that has if any))) wtime1,wtime2
?
That doesn't look like an improvement.  Mind you, MPI_DOUBLE doesn't sound like 
a convincing name for the kind either - I'd suggest MPI_WTIME_KIND myself.  Or 
pick one of the previous suggestions, but in any case it ought to be a 
documented value.

Cheers,
-- 
......................Malcolm Cohen, Nihon NAG, Tokyo.