[Numpy-discussion] Question about numpy.max(<complex matrix>)

[Stuart Brorson]

>> Is it NumPy's goal to be as compatible with Matlab as possible?
>
> No.

OK, so that's fair enough.  But how about self-consistency?
I was thinking about this issue as I was biking home this evening.

To review my question:

   >>> a
   array([[ 1. +1.j ,  1. +2.j ],
          [ 2. +1.j ,  1.9+1.9j]])
   >>> numpy.max(a)
   (2+1j)

Why does NumPy return 2+1j, which is the element with the largest real
part?  Why not return the element with the largest *magnitude*?
Here's an answer from the list:

> There isn't a single, well-defined (partial) ordering of complex numbers. Both
> the lexicographical ordering (numpy) and the magnitude (Matlab) are useful, but
> the lexicographical ordering has the feature that
>
>   (not (a < b)) and (not (b < a)) implies (a == b)
[snip]

Sounds good, but actually NumPy is a little schizophrenic when it
comes to defining an order for complex numbers. Here's another NumPy
session log:

   >>> a = 2+1j
   >>> b = 2+2j
   >>> a>b
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   TypeError: no ordering relation is defined for complex numbers
   >>> a<b
   Traceback (most recent call last):
     File "<stdin>", line 1, in <module>
   TypeError: no ordering relation is defined for complex numbers

Hmmmmmm, so no ordering is defined for complex numbers using the > and
< operators, but ordering *is* defined for finding the max of a
complex matrix.

I am not trying to be a pain, but now I wonder if there is a
philosophy behind the way complex numbers are ordered, or if different
developers did their own thing while adding features to NumPy?  If so,
that's cool.  But it begs the question: will somebody decide to unify
the behaviors at some point in the future?  Or are NumPy behaviors --
once defined -- never changed?

I ask because I am writing NumPy code, and I want to know if I will
find the behaviors changing at some point in the future.

Stuart