[Octave-bug-tracker] [bug #62485] sort does not sort

[Michael Leitner]

Follow-up Comment #4, bug #62485 (project octave):

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.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62485>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/