complex comparison ops vs. Matlab

[John W. Eaton]

On 27-Aug-2009, Jaroslav Hajek wrote:

| by this changeset:
| http://hg.savannah.gnu.org/hgweb/octave/rev/7dafdb8b062f
| 
| I finished my project of refactoring dense binary operator
| implementations in liboctave.

Thanks for taking on this project.

| One important point is that I changed the way comparing complex number works.
| I think that Matlab compares only real parts of complex arrays when
| involved in comparison operators; at least the previous Octave
| implementation did so.

Yes.  Not that it makes much sense (at least to me) but Matlab is
documented to work this way.

| OTOH, Matlab defines a rigorous ordering on complex numbers as the
| lexicographical ordering of [abs(z), arg(z)], which is used in sort,
| min and max, and is shared with Octave.
| I couldn't find the Matlab behavior documented anywhere,

Look at the alphabetical list of the documentation for Matlab
functions on the web.  Near the top of the page for relational
operators, it says

  The operators <, >, <=, and >= use only the real part of their
  operands for the comparison. The operators == and ~= test real and
  imaginary parts.

| However, it
| simplifies the implementation significantly to consider one universal
| ordering of complex numbers (defined in oct-cmplx.h) that gets
| automatically used everywhere.

Yes, I think it makes much more sense to have one definition for the
ordering.  Can anyone think of a case where it is really useful to
compare complex numbers using only the real part?good reason, then

| now hold for complex arrays as well (previously, this was not true).
| Personally, I think this new behavior is more logical and consistent
| and I vote for a change. I suppose few code depends on this and broken
| scripts can be trivially fixed by wrapping operands in real () (which
| I'd suggest anyway).

Yes, I agree that if you want to compare complex numbers by real part
only, then you should say so explicitly.

| If I'm outvoted on this, I'd still like to keep that Matlab
| compatibility mess out of liboctave, so I'll probably add a hack into
| the interpreter to apply "real" to the operands first. It could also
| be made conditional (for instance, keep the old behavior in the
| braindamage mode), but I think John already said he doesn't like
| global variables fundamentally influencing code flow.

What about an optional "matlab-incompatibility" warning?  Especially
since we are changing the behavior of Octave too, and this is the kind
of change that will otherwise silently change the results obtained
from of previously "working" code.

jwe