Re: Sorting complex values

[Ben Abbott]

> On Sep 27, 2014, at 1:44 PM, Rik <address@hidden> wrote:
> 
> All,
> 
> Could someone check the following under Matlab, just for confirmation?
> 
> x = [ [1 -1 i -i].' [1 -1 i -i]' ]
> angle (x)
> 
> Under Octave, this gives
> 
> octave:48> x = [ [1 -1 i -i].' [1 -1 i -i]' ]
> x =
> 
>   1 + 0i   1 - 0i
>  -1 + 0i  -1 - 0i
>   0 + 1i   0 - 1i
>  -0 - 1i  -0 + 1i
> 
> octave:49> angle (x)
> ans =
> 
>   0.00000  -0.00000
>   3.14159  -3.14159
>   1.57080  -1.57080
>  -1.57080   1.57080
> 
> The issue is the second line where -1 + 0i has a different phase angle then
> -1 - 0i.  Thus -1 can appear either first or last in the list produced by
> sort() depending on the phase angle.
> 
> octave:50> sort (x)
> ans =
> 
>  -0 - 1i  -1 - 0i
>   1 + 0i   0 - 1i
>   0 + 1i   1 - 0i
>  -1 + 0i  -0 + 1i
> 
> This is a little odd.  One would expect the sorted list to be the same
> which is indeed what Matlab does.
> 
> The question is whether we want to do anything about this, or should we
> just relegate it to being a quirk?
> 
> The actual comparison code is a macro in liboctave/util/oct-cmplx.h
> 
> #define DEF_COMPLEXR_COMP(OP, OPS) \
> template <class T> \
> inline bool operator OP (const std::complex<T>& a, const std::complex<T>& b) \
> { \
>  FLOAT_TRUNCATE const T ax = std::abs (a); \
>  FLOAT_TRUNCATE const T bx = std::abs (b); \
>  if (ax == bx) \
>    { \
>      FLOAT_TRUNCATE const T ay = std::arg (a); \
>      FLOAT_TRUNCATE const T by = std::arg (b); \
>      return ay OP by; \
>    } \
>  else \
>    return ax OPS bx; \
> } \
> 
> The std::arg for a C++ complex value internally calls atan2.
> 
> In terms of frequency of occurrence, I'd say it's not exactly easy to
> generate this situation, but it also isn't particularly hard.  At the
> interpreter level, Octave rationalizes '-0i' to '+0i' which makes it
> unlikely for user-generated input.
> 
> [-1-0i, i]
> -1 + 0i   0 + 1i
> 
> But it is easy to get the -0 with either complex() or by taking the conjugate.
> 
> complex (-1, -0)
> ans = -1 - 0i
> 
> [-1+0i, i]'
> ans =
> 
>  -1 - 0i
>   0 - 1i
> 
> Should we fix this?
> 
> --Rik

The current behavior looks correct to me. Am I missing something?

Ben