octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sorting complex values


From: Daniel J Sebald
Subject: Re: Sorting complex values
Date: Sat, 27 Sep 2014 16:02:05 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 09/27/2014 02:21 PM, Rik wrote:
On 09/27/2014 11:43 AM, Daniel J Sebald wrote:
Should we fix this?

Maybe.

First, complex numbers aren't an ordered field, so sorting is fraught
with peculiarities.  It's not really -1 being at a particular point in
the order, it's a number (-1) whose magnitude is the same as three others
and appearing at a perhaps arbitrary location.  Swap around the order in
which the magnitude 1 numbers are input and it might come out with a
different order output.

Matlab and Octave have placed an ordering on the field.  First magnitudes
are compared, and if those are equal then phase angles are compared.
Regardless of the input order in the vector, the sort always produces the
same result.  The question is how to handle inputs which most people would
consider identical (-1-0i and -1+0i), but which Octave treats differently.


The one thing that concerns me a bit is that -1 - 0i produces an angle of
-pi.  Typically when one speaks of argument (going from the complex
number to the argument and not vice versa) it is the principle argument,
having a range whose lower limit is open, i.e., (-pi,pi].  Often in phase
diagrams, the phase is unwrapped so that pi may be remapped to ..., -3pi,
-pi, pi, 3pi, ... but that is a secondary use.  So even though
atan(-1,-0) might produce -pi, maybe anything with -0 as the imaginary
component should be set equal to pi for the argument.


That is indeed the problem that we are inheriting from the atan2 function
which is defined on the closed range [-pi, pi].  We could unwrap the phase,
we could arrange for all -0i entries to be replaced with +0i entries before
the atan2 call, we could ignore it, we could ....?

This problem extends to the <, > and == operators, as well, I presume:

octave:105> x = [1 -1 i].'
x =

   1 + 0i
  -1 + 0i
   0 + 1i

octave:106> y = [1 -1 i]'
y =

   1 - 0i
  -1 - 0i
   0 - 1i

octave:107> x == y
ans =

   1
   1
   0

octave:108> x < y
ans =

   0
   0
   0

octave:109> x > y
ans =

   0
   1
   1

Looking at the result for the second element of the arrays, it seems that x(2) is both equal to and greater than y(2). A bug, I assume. I'm guessing the order operators are attempting to apply the same two-parameter sort rule, but using different code than sort(). Should I file a bug report?

Dan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]