[Octave-bug-tracker] [bug #53013] Comparison of complex values 2

[Michael Leitner]

URL:
  <http://savannah.gnu.org/bugs/?53013>

                 Summary: Comparison of complex values 2
                 Project: GNU Octave
            Submitted by: mleitner
            Submitted on: Tue 30 Jan 2018 10:26:33 AM UTC
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Feature Request
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.2.1
        Operating System: Any

    _______________________________________________________

Details:

I am splitting up bug #52919. Now to the most fundamental issue:

When Octave compares complex numbers, it first compares the absolute values
and then the phase angle (proviso bug #53011). For sorting, the same
comparison is used.

When Matlab compares complex numbers, it only considers the real part. For
sorting, it does the same as Octave. Thus, Matlab is not consistent. 

Octave wants to be consistent, and it wants to be compatible with Matlab.
Obviously, this is impossible, there are two internally consistent choices and
one compatible choice. As I will argue now, I would find the other consistent
choice better than the current one.

Actually, there is another criterion where it would be nice to be consistent,
which is how complex numbers with zero imaginary part are treated with respect
to comparison. Indeed, there is the concept of promotion and narrowing (for
the latter see bug #52919). Consider the following code:


a=(-2:2)'
a<0
a(4)=1i
a<0
a(1:3)<0
a(4)=5
a<0


a is created and the two negative elements are smaller than zero. When now any
value inside a is made complex, the whole vector a is promoted to class
complex, which changes the ordering relations, and no value is smaller than
zero (because the absolute value is now compared). When you only consider a
subset where every value has an imaginary part equal to zero, this vector is
again narrowed to class real, and everything works as before, the same when
you set the one complex value to real. I argue that this is also an issue of
internal inconsistency, because the result of the comparison of some elements
depends on the value of other elements (and when you have negative numbers,
this really is an issue). As far as I understand, Matlab is consistent in this
regard, as it only considers the real part, thus real numbers are a subset of
complex numbers with consistent ordering in this regard. Another nice
consequence of the Matlab-ordering is that it follows always from a<b that
a+c<b+c, whatever a, b and c (real or complex -- for Octave only one of the
three needs to be complex to potentially violate this law). 

So Matlab's ordering (which could be complemented by an imag-based ordering to
break ties on the real part and thus give a total order) has in my view more
nice properties than the abs-based ordering. If Octave switched to it (both
with respect to comparison as well as sorting), it would stay half-compatible,
it would stay consistent with respect to ordering and comparison, and it would
become more consistent (or at least intuitive, that is, less time taken for
hunting programming errors) with respect to seeing real numbers as special
case of complex numbers.

In fact, as I am not at all convinced that it is a good idea to blindly
compare complex numbers at all, for me it is not so important how the ordering
relations are defined on them. But what would help me was to introduce a
warning when I compare complex numbers, because I cannot remember ever doing
this intentionally. Rather, this would be a hint for a programming error on my
part and would have already saved me a few hours bug-hunting. Thus, when it
should be the consensus that it is a bad idea to change the ordering relations
on complex numbers at a whim, please consider this as a feature request for
such a warning (I see only unique as a valid use case for comparing complex
numbers, so there it should probably suppressed, if this is possible). 




    _______________________________________________________

Reply to this item at:

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

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