Subject: reduce on complex datatype

From: [email-masked] (Steve Huss-Lederman)
Date: Wed, 20 Jul 94 09:54:33 EDT

Hello All,

The issue of reduce on the complex datatype has gotten more involved
and contentious then I originally expected.  I see two basic points of
view (I'm not sure how many support each):

#1
Proposal:
Allow reduce on the complex datatype and define it to sort by the
modulus and return the max entry.  Ties are broken by returning entry
with lowest rank.  This is basically the proposal I put out after the
first round of comments.

Arguments for: 
-This seems the most natural definition to most and is consistant with
the other reduce functions.  
-MPI supports reduce on all datatypes instead of having an exception for
complex.
-It clarifies the text already in the standard MPI document
-Some users want this and will use it.

#2
Proposal:
Drop the definition of reduce on complex datatypes

Arguments for:
-There is more than one possible definition of what reduce does on a
complex type.  Sort by modulus, real, etc.; return modulus, entry,
etc.
-This only applies to Fortran binding of MPI (since complex only
exists there) and standard FORTRAN does not support MIN, MAX, MAXLOC,
MINLOC on the FORTRAN complex datatype.
-You can get the same functionality by creating a second floating
point (real,double) array arry and making its entries the modulus of
the complex array.  Then simply take the MAXLOC,MINLOC of the second
array and use the index returned to get the value from the first
array.

What to do:

The correct action is not clear to me.  p. 113 and 115 of the April 15
draft allows for reduce on the complex datatype (though it is not well
defined).  I viewed #1 as a clarification of the text (which most seem
to support if you can reduce on complex values).  #2 is removing
functionality that exists in the current draft (I don't view this as a
clarification; I think it is a change).  I think both positions have
merit and each is supported by some fraction of those participating in
the discussion.

I don't know how the resolution is done and what the rules really are.
I don't recall clearly defining how such changes would occur.  I think
this applies to several other items that are being discussed here.  I
think the time has come to define how we vote on items such as this
since there are no planned meetings.  I don't think a single person
should be making these decisions.

I'll stick my neck out and throw out a proposal for voting.  This is
just to get the discussion started.  It clearly needs refining and
input from others.

Proposal for votes to decide issues:
-A vote should be called when a proposal has been made that changes
the current draft and seems reasonable after a discussion period.  A
vote is also taken when a clarification is not clearly decided after a
discussion period.
-I think mpi-core is the logical place for all messages to be posted.
I have no problem with them also being posted to comp.parallel.mpi but
since we may not want the whole world involved in the votes, I think
the minimum is a post to mpi-core.
-A clear written proposal of the choices and what a vote would mean
MUST be posted.  This proposal MUST include the exact text that would
go into the standard document and where it would be placed.
-A discussion period on the vote begins.  Since people are away at
times, I think it should last a reasonable period of time.  At least 2
weeks; maybe a month.
-Any modification to the original proposal MUST be clearly written out
in the same mannor as the original proposal.  This essential begins a
new discussion period and delays any possible vote.
-Someone needs to call a formal vote and moderate proposals if there
is contention.  To be consistant with the the meetings, the primary
author of the chapter (or someone the author requested to act for him/her)
would do this.  If this cannot happen then Steve Otto could do this as
the master editor. 
-Once a formal vote is called, the voting rules are the same as at the
meetings.  Only one vote per institution.  The 2 out of 3 meetings
rule is a little strange here.  How about you can only vote if you
formally voted (or could have) in 2 of the last 5 meetings.  This will
hopefully include anyone who was active in the last half of the MPIF.
Someone should create a e-mail drop box to collect votes.   The voting
period would be 2 weeks.  Some adoption rules would apply as at the
meeting: majority carries.
-I don't think we need to vote on something twice at this point like
we did at the meetings.

Comments?  If we agree on how to vote, I will post a proposed vote on
reduce for complex values.

Steve