[Mpi-forum] MPI_2COMPLEX etc

Wed Feb 17 08:50:13 CST 2010

Bill and members of the Forum

I have been in contact with the developers who had included MPI_2COMPLEX
and MPI_2DOUBLE_COMPLEX in their open source library. It turns out they had
never made any judgement about whether these datatypes were useful or
logical.  Because their package sits between the MPI implementation and
their users, they wanted their offering to be "complete" with respect to
what they understood to be in the MPI-2 standard.

They are removing MPI_2COMPLEX and MPI_2DOUBLE_COMPLEX immediately. If MPI
implementations were to remove these datatypes in a few months, at least
the one library I ran across that depends on them would have left that
behind.

I do not know if there is anyone we would break by removing them decisively
but I think it is reasonable to consider doing it.

            Dick

Dick Treumann  -  MPI Team
IBM Systems & Technology Group
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
Tele (845) 433-7846         Fax (845) 433-8363

  From:       William Gropp <wgropp at illinois.edu>                                                                                 

  To:         Main MPI Forum mailing list <mpi-forum at lists.mpi-forum.org>                                                         

  Date:       02/16/2010 01:36 PM                                                                                                 

  Subject:    Re: [Mpi-forum] MPI_2COMPLEX  etc                                                                                   

  Sent by:    mpi-forum-bounces at lists.mpi-forum.org                                                                               

I did some searching and I was reminded that *removing* MPI_2COMPLEX
was one of the errata items from the MPI-1 specification.  The 1.0
Spec had these (see pages 115, line 42 and 209, line 12).  An errata
removed them.

So these were part of MPI, but were withdrawn.  An implementation that
dates back to 1.0 could be expected to include these (and have
forgotten or decided not to withdraw them).  These names weren't
invented (I fully agree that MPI implementations must not create new
names that begin with MPI_).  And yes, MPICH/MPICH2 is such an
implementation (I've found MPI_2COMPLEX defined in MPICH-1 header
files dating back to 1994).  We probably left it in for reasons of
backward compatibility for any applications written for MPI-1.0.

The text in MPI-1.0 doesn't define what is meant by the max or min of
a complex value; a tricky question is how to make it reduce to the
case of max/min on reals in the case that the imaginary part it zero.
Though I don't remember the discussion on the errata, that's probably
why we decided to remove MPI_2COMPLEX from MPI 1.1.  If there is an
application that makes use of them, then perhaps we should consider
whether the standard should restore these types and the related
operations.

Bill

On Feb 16, 2010, at 11:07 AM, Richard Treumann wrote:

> Some MPI implementations have added new, predefined datatypes that
> are not in the MPI Standard. These are the the MIN_LOC/MAX_LOC
> operands MPI_2COMPLEX and MPI_2DOUBLE_COMPLEX. There is now at least
> one widely used application that depends on MPI_2COMPLEX. That
> application does not port to any MPI which lacks the non-standard
> MPI_2COMPLEX type.
>
> I do not recall any discussions about MPI_2COMPLEX but they probably
> did occur. Some people seem convinced MPI_2COMPLEX is part of
> MPI-2.0. I searched both 2.0 and 2.2 without finding them.
>
> I think the ambiguity in the meaning of less_than / greater_than
> when applied to complex numbers would be a good reason to consider
> leaving the datatypes and the associated MIN_LOC & MAX_LOC
> operations out of any standard. The idea of returning a location in
> a complex number is sort of ugly too but well enough defined to be
> acceptable.
>
> My understanding, going back to MPI 1.1 days, is that MPI
> implementations were to avoid inventing names with an MPI_ prefix so
> any name with that prefix could be used safely by follow-on MPI Fora
> that were extending the standard.
>
> We do now have these MPI_ names among users and people are assuming
> the should be able to use them portably. I think the Forum needs to
> take a position and either add them to the standard (with a clear
> definition of MPI_LOC and MAX_LOC behavior) or deprecate them.
>
> Dick
>
>
> Dick Treumann - MPI Team
> IBM Systems & Technology Group
> Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601
> Tele (845) 433-7846 Fax (845) 433-8363
> <ATT00001..txt>

William Gropp
Deputy Director for Research
Institute for Advanced Computing Applications and Technologies
Paul and Cynthia Saylor Professor of Computer Science
University of Illinois Urbana-Champaign

_______________________________________________
mpi-forum mailing list
mpi-forum at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20100217/29255a55/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20100217/29255a55/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20100217/29255a55/attachment-0003.gif>