Re: complex comparison ops vs. Matlab

[Jaroslav Hajek]

On Thu, Aug 27, 2009 at 10:02 PM, John W. Eaton<address@hidden> wrote:
> 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
>

Right now I can't think of any (which doesn't mean there isn't any),
but even if it is, it can be done with real (), which will also be
more readable. On the contrary, getting the complex ordering is not
trivial. For instance, how would you check that a complex array is
strictly upwards sorted in Matlab? Compare
za = abs (z); zf = arg (z); all (za(1:n-1) < za(2:n) || (za(1:n-1) ==
za(2:n) && zf(1:n-1) < zf(2:n))
to the simple
z(1:n-1) < z(2:n)

But of course, it's primarily the inconsistency with max/min/sort that
makes the Matlab behavior nutty. Also, the complex ordering defined by
sort is consistent with complex equality (one of <, >, == is always
true, except for NaNs) but comparison by real parts isn't. It' also
consistent with the normal ordering of reals.

>
> | 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
>

OK, that would probably work best. And the warning on in traditional
mode, I suppose. I'll try making a patch.

regards

-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz