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

[Robert Kern]

Stuart Brorson wrote:
>>> 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

No, that's a Python session log and the objects you are comparing are Python
complex objects. No numpy in sight. Here is what numpy does for its complex
scalar objects:

>>> from numpy import *
>>> a = complex64(2+1j)
>>> b = complex64(2+2j)
>>> a < b
True

> 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?

We do try to keep backwards compatibility.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco