bugGNU Octave - Bugs: bug #62485, sort does not sort

 
 

bug #62485: sort does not sort

Submitter:  None
Submitted:  Wed 18 May 2022 03:07:54 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Invalid / Not an Octave Bug Assigned to:  None
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 7.1.0
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 18 May 2022 08:44:30 AM UTC, comment #4: 

Yes, you are right: (a<=b) implies (a*c<=b*c) holds only for non-negative real c. But for complex c it holds always, which is an indication of the issue that I have the most problems with: if you have a negative real c and add the smallest imaginary part to it, the result of the comparison changes. Also if you have arrays of complex numbers where some members have zero imaginary part and compare subsets of the arrays (by indexing into them), then it can be that the exactly same two numbers compare differently, depending on whether the indexing extracted only numbers with zero imaginary part or not (in the first case, you get automatic narrowing to real  arrays and thus comparison as defined on real numbers, in the latter comparison on the magnitude also for pairs of elements that both are purely real). In matlab's convention, all these issues would vanish.

Yes, octave's sort is compatible with matlab's sort in the default case. However, matlab's sort since r2017a can optionally be indicated to use different comparison methods. This is not yet in octave, see bug #54900. I would say that when this capability comes to octave, at least then you could switch and the only matlab incompatibility would be in terms of the default behaviour of sort (where you could however choose matlab-compatible behaviour).

Yes, the other reports would be the place to discuss it. I presented my arguments there, and I think just reiterating them would be rude. If you have a arguments to contribute, I would be happy if you did it there, to perhaps redirect attention to this issue.

Michael Leitner <mleitner>
Wed 18 May 2022 08:20:24 AM UTC, comment #3: 

@Michael: Got your point. I was probably too sloppy in what I wrote.
So, we'd either break "if a<=b then a*c<=b*c for any a, b and c" (is this true for real numbers if c < 0?) or "f a<=b then a+c<=b+c for any a, b and c". That's more or less what I tried to describe (with admittedly questionable success).

IIUC, Octave's `sort` function is compatible with Matlab (at least it was at some point in the past iirc).

It'd probably be best to continue discussion on one of the other two reports which already have a few comments regarding this.

Markus Mützel <mmuetzel>
Group administrator
Wed 18 May 2022 07:47:26 AM UTC, comment #2: 

Depending on your point of view, this is a Matlab incompatibility feature or bug (to me, the latter). For context see the discussion in bug #52919 and bug #53013.

Markus: you can define an order on any set, any order you like. In this sense, any set is orderable. The point is only that the complex numbers as a field, that is, a set together with two binary operations fulfilling some conditions, in the specific case addition and multiplication, cannot be equipped with an order relation that is compatible with the field operations. In this sense the complex numbers cannot be made to be an ordered field. Octave compares on the absolute value, therefore complex multiplication is compatible with ordering: if a<=b then a*c<=b*c for any a, b and c (also complex). Matlab does it differently, it sorts on the real part, and therefore addition is compatible with ordering: if a<=b then a+c<=b+c for any a, b and c.

This is the reason for the OP's observation (as octave's sorting behaviour follows from its comparison operators). I maintain that I would be in favour of switching to matlab's definition of complex order, potentially augmented by comparing the imaginary entries for tied real entries, which would solve a number of issues mentioned in above-quoted discussions. Matlab's sort since r2017a has an option to allow to specify the comparison method, while by default it still compares on the magnitude. If octave makes the switch in the relation operators, the default behaviour of sort and friends, and max and friends, and in addition implements Matlab's arguments for the comparison method in sort and max, it is consistent within itself and compatible with matlab in anything but the default method used in sort (but matlab-compatible behaviour could be specified), while now it is incompatible in the relation operators and max.

Michael Leitner <mleitner>
Wed 18 May 2022 06:32:59 AM UTC, comment #1: 

Complex numbers aren't orderable per definition (see, e.g., [1]). To make it possible to have a more-or-less consistent result of sorting them anyway, additional rules must be applied (that will always break some of the rules that would apply for orderable fields).

The additional rules that Octave has chosen to apply are documented in the help string for `sort`:

> Sorting of complex entries is done first by magnitude (abs (z)) and for any ties by phase angle (angle (z)).


That seems to be working as documented in your example.

Closing as invalid.

[1]: https://en.wikipedia.org/wiki/Ordered_field

Markus Mützel <mmuetzel>
Group administrator
Wed 18 May 2022 03:07:54 AM UTC, original submission:  

If a < b < c, then a+a < a+b < a+c, a+b < 2b < b+c, and a+c < b+c < 2c. But that is violated like this.



a = sort ([1 -1 0 i -i])
c = a.' + a
sort (c,1) == c
sort (c,2) == c


The two results from the last two lines should be all ones. When a is all real numbers it is all ones. For complex no.

Anonymous

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mleitner (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-05-18 mmuetzel CategoryLibraries Octave Function
        Dependencies- Depends on bugs #53013
        Dependencies- Depends on bugs #52919
    2022-05-18 mmuetzel StatusNone Invalid / Not an Octave Bug
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code