[Octave-bug-tracker] [bug #63962] perms - Performance - Usage of native C++ algorithm helpful

[Nicholas Jankowski]

Follow-up Comment #11, bug #63962 (project octave):

to close off my topic derailment - 

a decade ago it was agreed that matlab didn't dictate ordering and octave
likewise shouldn't try to chase undoc'd behavior. (bug #30114)

at some point in the pre-2015 timeframe, matlab added a declaration that
ordering was reverse lexicographic. but there was matlab bug report such that
2013-15 matlab didn't follow it's own specification.  Apparently that was
fixed after 2015, acknowledged by bug #50426 and octave implemented the
equivalent of sortrows(perms(x)) to follow suit. 

However, as discussion around that matlab bug in
https://www.mathworks.com/matlabcentral/answers/248750-the-working-of-perms#comment_316425
it is explained that "Reverse lexicographical order" does not refer to the
value of the inputs. it refers to the ordering of the inputs.  so (checking
with v2022b) an input of perms([1 2 3]) as expected produces:


>> perms([1 2 3])
ans =
     3     2     1
     3     1     2
     2     3     1
     2     1     3
     1     3     2
     1     2     3


while perms ([2 1 3]) appears as:


>> perms([2 1 3])
ans =
     3     1     2
     3     2     1
     1     3     2
     1     2     3
     2     3     1
     2     1     3


if it was value-based reverse lexicographical sorting, both would be the same
and match sortrows(perms([2 1 3])), as octave currently does.

However, Matlab is doing order-based sorting.  (two examples above have the
same positional sorting if you just swap with the 2 and the 1).

in conclusion - matlab's perms is now sorting consistent with it's stated
documentation, if you understand it's wording to not simply mean what it says.
 Octave, doesn't currently do this. 

Bringing it back home:  i think unique should match similar to the base
sorting case. I'm not sure how to do that with low overhead, but assume the
order passed to unique could be retained with the I J outputs. separately,
i'll comment about the octave-matlab mismatch over on the other report.


    _______________________________________________________

Reply to this item at:

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

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