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

Eric Firing efiring@hawaii....
Fri Sep 21 20:11:03 CDT 2007


Stuart Brorson wrote:
> On Fri, 21 Sep 2007, Robert Kern wrote:
>> 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
> 
> OK, fair enough.  I was wrong.  But, ummmmm, in my example above, when
> you find the max of a complex array, you compare based upon the *real*
> part of each element.  Here, you compare based upon complex
> *magnitude*.

No. It is a matter of sorting first on the real part, and then resolving 
duplicates by sorting on the imaginary part.  The magnitude is not used:

In [21]:a = complex64(2+1j)

In [22]:c = complex64(1.99+2j)

In [23]:a>c
Out[23]:True

In [24]:amin([a,c])
Out[24]:(1.99000000954+2j)

In [25]:amax([a,c])
Out[25]:(2+1j)

In [26]:a<c
Out[26]:False


Eric


More information about the Numpy-discussion mailing list