[Mpi-forum] MPI Count proposal from today's meeting

[N.M. Maclaren]

On Jun 18 2010, Supalov, Alexander wrote:
>
> Thanks. Let's agree on what we call the "short int" and the "default 
> int". For me, "short int" is historically a 2-byte signed entity. I'm 
> thinking of the "default int" as a 4-byte signed entity. I know there 
> were many other approaches, but I am intentionally going with the current 
> mainstream here. With this, do we use these terms in a comparable manner?

Not really.  I remember when a short integer was 12 bits, sometimes 10 or
even 8 :-)

More seriously, MPI currently has precisely one kind of integer, but uses
them for two purposes, one 'short' and the other 'long'.  The former is
anything like ranks, error numbers, tokens, tags, yada, yada.  The latter
is vector counts and offsets.  Let's skip MPI_Aint here.

The former is quite reasonably mapped to the languages default integer,
and I hope that continues.

> As to the reasons not to delve into the unsigned jungle, I agree with 
> your arguments, especially those from your first reply.

Good.

> Irrespective of 
> this, the use of the MPI_UNDEFINED in the MPI_GET_COUNT looks a little 
> careless now that the MPI_Count may be larger than the default int (in 
> the above understanding). We'd probably fare syntactically cleaner with 
> the MPI_COUNT_UNDEFINED of the respective size (cf. MPI_PROC_NULL).

It's a reasonable viewpoint, and I think that I agree.

> In some sense, I assume that the MPI_UNDEFINED was initially added to the 
> MPI_GET_COUNT return value range out of utility consideration, like, "we 
> already have the MPI_UNDEFINED, why not using it here, too?" It is this 
> initial motivation, if it indeed was comparable, that may need review 
> now.

It's only an actual problem if anyone is insane enough to use MPI interfaces
without proformas, and that's deprecated in all of C, C++ and Fortran.  But
cleaning it up would not be a major problem - it's not heavily used, anyway.

Regards,
Nick Maclaren.