# bug #53880: (x<1)(1) depends on x(2):

 Submitted by: deego Submitted on: Fri 11 May 2018 08:09:43 PM UTC Category: Octave Function Severity: 3 - Normal Priority: 5 - Normal Item Group: Matlab Compatibility Status: None Assigned to: None Originator Name: DAVE GOEL Open/Closed: Open Release: 4.2.2 Operating System: GNU/Linux

Add a New Comment

You are not logged in

Please log in, so followups can be emailed to you.

## Discussion

Mon 14 May 2018 07:13:35 AM UTC, comment #11:

Michael L said:
So the upshot: it is desirable to have a well-defined total order also on complex numbers, even if you are not interested in the specific ordering.

========================
This appears to be the best solution. The lexicographic ordering
is fairly "natural" and efficient. Other orderings seem to be
"special cases." It will deserve a clear explanation in the Manual.
In any case, users who have a specific need to "sort" complex numbers
will likely need to choose an ordering that meets their requirements,
and/or preprocess the data.

Michael Godfrey <godfrey>
Mon 14 May 2018 06:41:28 AM UTC, comment #10:

It's just that the complex numbers are not an ordered field, that is, there is no total order that is compatible with how the natural ordering relation on the real numbers behaves under addition and multiplication. However, as with any set you can also assign a total order to the complex numbers. As I see it, the most intuitive one would be the lexicographic order that is implied by understanding the complex numbers as the Cartesian product R x R, with the two added advantages that in this case the real numbers as R x {0} would then be order-embedded in the complex numbers, and that the numerical effort of a complex comparison would be only insignificantly larger than a real comparison, compared to the present case where two abs() have to be computed for every comparison (and sometimes even two atan2()s).

And if you error out for every complex comparison, you break unique() and thus union(), setdiff() and so on as they are now and need to emulate their behaviour by an explicit unique([real(a)(:) imag(a)(:),"rows") followed by reshaping, which is significantly less efficient and more memory-consuming. So the upshot: it is desirable to have a well-defined total order also on complex numbers, even if you are not interested in the specific ordering.

Michael Leitner <mleitner>
Sun 13 May 2018 09:01:14 AM UTC, comment #9:

Mathematically, the complex numbers are not an ordered set. So formally, any attempt to sort them should produce an error.

However, there are subsets of the complex numbers in which the attempt to produce an order makes some sense. For example, in the case of a vector which results from calculations where the imaginary parts formally would all be zero but some may have accidentally a very small value caused by numerical inacurrancy.

So what about throwing just a warning in cases where all available sort methods would produce the same order but an error when there are different results for the possible methods and no method has been explicitely defined? Same for max and min.

Lars Kindermann <larskindermann>
Sat 12 May 2018 08:16:51 PM UTC, comment #8:

My preference would even be an outright error.  I mean, I'd hope there is no code in any packages that are expecting some type of behavior for the order operators on complex numbers or vectors.  It's not very difficult to explicitly indicate

octave:12> (real(x)<1)(1)
ans = 1
octave:13> (abs(x)<1)(1)
ans = 0

or for vectors

octave:30> x = magic(3);
octave:31> norm(x,'cols') < 10
ans =

1  0  1

Dan Sebald <sebald>
Sat 12 May 2018 07:30:09 PM UTC, comment #7:

I would be satisfied with a warning, on by default. As I mentioned in bug #52919, the way I initially came upon this problem was that it resulted in incorrect behaviour of code of mine, because I used vector comparisons, where sometimes the vector had (a very small number of) complex entries, just as the original reporter of the present bug describes. A warning would have made me immediately aware of the problem.

I can think of only one legitimate use case of comparing complex values, to wit, the function unique. But actually, in this case the total ordering is only necessary for the sort that goes on in the background, and any total order would do. Would there be some way to selectively disable the warning in a sort (or sortrows) that is called from unique? Because it is obviously perfectly valid to request the unique values of a complex vector. All other uses of sort, max, bare < and so on should in my eyes rather explicitly form and compare the absolute values, angles, real parts or whatever.

So actually there is a further argument for changing the ordering on complex numbers to lexicographic ordering: It has significantly higher performance (see bug #53012). So this would allow unique to run much faster on complex vectors than is possible with the present choice without using any additional memory.

Michael Leitner <mleitner>
Sat 12 May 2018 07:40:47 AM UTC, comment #6:

I agree, too. A warning when try to order complex values seems the right thing.

Marco Caliari <caliari>
Fri 11 May 2018 11:25:28 PM UTC, comment #5:

That seems right.  Unless the programmer has explicitly told Octave which sorting method to use, emit a warning.  This is too difficult a decision to leave up to some heuristic which, no matter how it chooses, it going to get it wrong for some users.

Rik <rik5>
Fri 11 May 2018 09:20:16 PM UTC, comment #4:

So, we should warn in all cases when attempting to order complex values unless explicitly told to use a particular method of ordering.

John W. Eaton <jwe>
Fri 11 May 2018 09:14:03 PM UTC, comment #3:

Yes, I think it was the sort function that now has an option to sort by real value or by abs value, but not max and min.

So if we do become Matlab compatible, the next bug reports will be

Think of a strange scenario where x < y is true, but max([x y]) returns x.

Mike Miller <mtmiller>
Fri 11 May 2018 09:08:41 PM UTC, comment #2:

I guess this is the bug that will not die.

Even though this will make the comparison used in the <, <=, >=, and > different from the behavior of min and max, maybe we should just finally give in and submit to the way that Matlab works.

How about also a warning (you may disable if you wish) when using <, <=, >=, or > to compare complex values?

John W. Eaton <jwe>
Fri 11 May 2018 09:02:01 PM UTC, comment #1:

Yes, I have described these issues already at some length in bug #52919 and bug #53013. I would also be in favour of changing the ordering relation on complex numbers to lexicographic, which would solve all the mentioned problems of counter-intuitive behaviour and additionally bring about matlab compatibility.

Michael Leitner <mleitner>
Fri 11 May 2018 08:09:43 PM UTC, original submission:

QUIZ:  Think of a strange scenario where the result of (x<1)(1)  depends on the value of x(2) (!)

Yes, there's such an a possible:

x=[-2 -1] and x = [-2 i] return different answers for (x<1)(1).

That's because octave switches to abs() if it encounters complex numbers.

The problems with this, in my opinion, are:

(1) Strange logic above of result(1) depending on x(2).

(2) A strange discontinuity in y<1 between y = -2 and x = -2 + eps i

(3) Matlab, see below.

(4) As it stands, < is therefore useless and unreliable when using complex numbers. You cannot consistently rely on it to use abs, since you never know when x will be interpreted as real.

A more consistent approach seems to be to use Re() instead of Abs() when comparing complex numbers.  Instead of any strange behaviors as above, that transitions smoothly when x becomes real.

Finally, matlab seems to use the behavior I recommended: https://www.mathworks.com/help/matlab/ref/lt.html#bt297ps-5

deego <deego>

## Attached Files

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Comment:

No files currently attached

## Dependencies

Depends on the following items: None found

Items that depend on this one: None found

## Mail Notification Carbon-Copy List

Carbon-Copy List
• -email is unavailable- added by godfrey (Posted a comment)
• -email is unavailable- added by larskindermann (Posted a comment)
• -email is unavailable- added by sebald (Posted a comment)
• -email is unavailable- added by caliari (Posted a comment)
• -email is unavailable- added by rik5 (Posted a comment)
• -email is unavailable- added by mtmiller (Posted a comment)
• -email is unavailable- added by jwe (Posted a comment)
• -email is unavailable- added by mleitner (Posted a comment)
• -email is unavailable- added by deego (Submitted the item)
• -email is unavailable- added by deego
•

Do you think this task is very important?
If so, you can add your encouragement to it.
This task has 0 encouragements so far.

Only project members can vote.

## History

Follows 1 latest change.

Date Changed by Updated Field Previous Value => Replaced by
2018-05-11 deego Carbon-Copy- Added -email is unavailable-