Re: Sorting complex values

[Rik]

On 09/27/2014 02:02 PM, Daniel J Sebald wrote:
> 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?
>

Yes, probably best to have a record of this.  I'm sure the problem is that
the equality comparison '==' is done in rectangular form so x1 + iy1 == x2
+iy2 is done by x1 == x2 && y1 == y2.  But -0 == 0 so the two are equal. 
the relational operators used for sorting '<' and '>' compare values in
polar form where the different phase angle is important.

--Rik