Subject: complex. sigh.

From: Steve Otto <[email-masked]>
Date: Mon, 18 Jul 94 16:37:18 -0700

In a blinding flash of clarity, Jim Cownie said:

>This doesn't actually change anything, because for all the other types
>the input element which has the max or min value IS identically the
>max or min value. 

	So it just isn't such a big deal, and no, we aren't changing 
	the standard.

	We also hear:

>So we are saying that we take the max/min for complex according to
>modulus thereof.  Why dont we just not offer max/min of complex in MPI. 
>In no other case do we offer max/min of function(data), just max/min of
>data.  The user can easily store the modulus in a real (or double)
>array, and do max/min on that. 

	Ah...no.  Think like a Fortran person.  COMPLEX is fundamental
	and a Fortran person wants the operation.

	What is this business about this one being so special because it
	uses a "function"?  They *all* use a function, it's just that in
	some cases the function looks a little simpler than in other cases.
	No big deal.  What we have decided upon is natural for type COMPLEX.
	And remember that there is no C datatype corresponding to type
	MPI_COMPLEX.

	--Steve Otto

---

From: [email-masked] (Cherri Pancake)
Date: Tue, 19 Jul 94 13:47:48 PDT

Hear, hear.  Steve Otto is right on the mark with:
> Think like a Fortran person.  COMPLEX is fundamental

The suggestion that we not offer max/min of COMPLEX will
	- set a dangerous precedent for we-almost-apply-this-to-all-data
		types-but-not-quite
	- force programmers to roll their own, since they really need
		this

Cherri Pancake

---

From: [email-masked] (Peter Pacheco)
Date: Tue, 19 Jul 94 17:01:17 PDT

It's not clear to me that if w and z are complex, then "max(z,w)" should
necessarily return the argument with the largest modulus.  I can easily
imagine that someone would want the argument with the largest real part.
This would generalize max applied to real values, since, for example,
max(-2,1) is 1.  (Of course, with max(z,w) = argument with larger modulus, 
max(-2,1) is -2.)

Incidentally, Leslie's program won't compile on our RS 6000 or our
nCUBE -- neither fortran compiler accepts complex arguments to max.

So I vote that the action of reduce with complex arguments and the
various max/min operations be undefined.

					Peter

---

From: Tony Skjellum <[email-masked]>
Date: Tue, 19 Jul 94 18:11:55 CDT

----- Begin Included Message -----

---

From: [email-masked] (Cherri Pancake)
Date: Tue, 19 Jul 94 13:47:48 PDT

Cherri Pancake

----- End Included Message -----

Various expositors,

Absolute value min and max make sense for complex, just by generalizing
the idea of modulus to be the usual modulus for complex.  If this is what
Steve means, fine.  If we mean to leave that out, I think we are making
a mistake.

However, regular complex min/max do not make sense.  There is no
mathematical operation for min(c1,c2) where c1 and c2 are complex.  Why
provide an operation for symmetry when there is no mathematical
analog?  This seems empty to me.  min and max are a statement of the
ordering of the real numbers or integers!  Why should MPI define a
meaning?  (You can argue than minrealpart, mincomplexpart, minabsrealpart,
minabscomplexpart, and max versions of these 4 are meaningful, however).

I do not think that users will want operations that do not make sense
mathematically regardless of symmetry that might provide!?!?!?!

-Tony Skjellum