In reply to your reply (which I inadvertently deleted :-[ ) to my reply:
Point well-made and taken. :-)
DG
Stuart Brorson wrote:
>> 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:
>>
> [sni
On Fri, 21 Sep 2007, David Goldsmith wrote:
> Not to be snide, but I found this thread very "entertaining," as,
> precisely because there is no single, well-defined (partial) ordering of
> C, I regard it as poor coding practice to rely on whatever partial
> ordering the language you're using may (
Apparently so.
Not to be snide, but I found this thread very "entertaining," as,
precisely because there is no single, well-defined (partial) ordering of
C, I regard it as poor coding practice to rely on whatever partial
ordering the language you're using may (IMO unwisely) provide: if you
wan
> 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:
[snip]
Oh, OK. So the ordering algorithm for complex numbers is:
1. First sort on real part.
2. Then sort on imag part.
Right?
Stuart
On Fri, Sep 21, 2007 at 08:27:51PM -0400, Stuart Brorson wrote:
>>>> a
>array([[ 1. +1.j , 1. +2.j ],
> [ 2. +1.j , 1.9+1.9j]])
>>>> numpy.max(a)
>(2+1j)
This is numpy. You are dealing with arrays, so its numpy.
>>>> a = 2+1j
>>>> b = 2+2j
>>>> a>b
>Tra
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 eveni
>> 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
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
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 que
Stuart Brorson wrote:
> Is it NumPy's goal to be as compatible with Matlab as possible?
No.
Whatever gave you that idea? That's what Octave is for.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959 voice
7600 Sand Point Wa
Stuart Brorson wrote:
> Thank you for your answer!
>
>>> As a NumPy newbie, I am still learning things about NumPy which I didn't
>>> expect. Today I learned that for a matrix of complex numbers,
>>> numpy.max() returns the element with the largest *real* part, not the
>>> element with the larges
Thank you for your answer!
>> As a NumPy newbie, I am still learning things about NumPy which I didn't
>> expect. Today I learned that for a matrix of complex numbers,
>> numpy.max() returns the element with the largest *real* part, not the
>> element with the largest *magnitude*.
>
> There isn't
Stuart Brorson wrote:
> Hi guys,
>
> As a NumPy newbie, I am still learning things about NumPy which I didn't
> expect. Today I learned that for a matrix of complex numbers,
> numpy.max() returns the element with the largest *real* part, not the
> element with the largest *magnitude*.
There isn'
Hi guys,
As a NumPy newbie, I am still learning things about NumPy which I didn't
expect. Today I learned that for a matrix of complex numbers,
numpy.max() returns the element with the largest *real* part, not the
element with the largest *magnitude*.
Is this the desired behavior?
Here's an exa
14 matches
Mail list logo
