[Octave-bug-tracker] [bug #52919] comparison of complex values

[Michael Leitner]

Follow-up Comment #5, bug #52919 (project octave):

Yes, I definitely subscribe to the order relations being consistent with sort,
min and max. As has been said, Matlab is (by default) not consistent in these
three functions, and only for sort, the behaviour can be specified (they do
not say anything about median and the like -- of course, Octave is again
consistent).

However: I think, all of us are deeply convinced that real numbers are just a
special case of complex numbers. All arithmetic operations when performed on
complex numbers with imaginary part equal to zero reduce to those on the real
numbers, and also all typical analytical functions like exp, sqrt, log and so
on do. This is also the reason why Octave without being asked gives a real
vector D 

D=C(i)


for complex C, when all C(i) have imaginary part zero. However, only the
ordering relations as Octave use it are inconsistent between C and D (that is,
for very different x and y, when you add 1i*eps to x, they can order
differently than without). Matlab's ordering relations would be consistent.
That's why I like them better, and if there were no questions of backward
compatibility, I would argue for changing it (whatever the compatibility with
Matlab).

Further however: I think that in the vast majority of cases when complex
numbers are compared (perhaps with the exception of the function unique), this
is done erroneously. Apart from this, I see no use-case for ordering complex
numbers. And when I would like to sort as Octave's sort does it now, I would
do

A=complex(randn(10,1),randn(10,1))
B=sort(A)
[~,j]=sort(arg(A))
A=A(j)
[~,j]=sort(abs(A))
B1=A(j)
all(isequal(B,B1))


and analogously for Matlab's 'ComparisonMethod','real' (yes, vastly less
efficient, but when there is no use-case, who cares?). In the case where I
stumbled over this behaviour, I actually was aware that with small probability
some entries in the two vectors I compared could be complex. These entries
would have been sifted out afterwards, but in fact these few entries made the
whole vector complex, thus the ordering of the whole vectors (for the negative
values) was different.

Another example: do you think that x<y implies x+10<y+10? Yes, I do also, and
I would not be surprised when this is assumed deep inside some internal Octave
functions, but for Octave's complex comparison this is not the case. So as I
think that comparing complex numbers for order (of course not for equality) is
done in most cases unintendedly, I propose to emit a warning (the first time).
I am someone who does read error messages, and this would really have been
useful for me. 

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52919>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/