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 _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
