[Octave-bug-tracker] [bug #50426] perms() sort order different than Matlab

[Rik]

Follow-up Comment #9, bug #50426 (project octave):

Also, see the bug report #30114 which is the same issue reported 7 years ago. 
As documented then, there was a reluctance to change the function because
there was no stated ordering by Matlab and there was the very real possibility
that Matlab would change its ordering in the future.  That is confirmed in
comment #0 where the behavior changed from R2015B to R2016B.  If you must have
a specific order for a set of permutations then your scripts should ensure
that in some manner.

On the other hand, Octave is always happy to have faster, high-performance
code.  The calculation in the existing perms.m was specifically done in uint8
to limit memory consumption.  How bad is the performance hit that you talk
about?

I used an input of 1:10 to both perms.m and perms_new.m and ran both through
the debugger to inspect the memory usage.

For perms.m:


B = 3,628,800 bytes
p = 36,288,800 bytes
A = 290,304,000 bytes


Essentially, 40MB worth of intermediate values.

For perms_new.m


idx = 26,127,360 bytes
perm = 2,580,480 bytes
A = 290,304,000 bytes


The new method only has 28.5MB of intermediate values so it is an improvement
on the old script.

The script needs to be updated to follow Octave coding conventions, and I
would like an estimate of the performance hit to use uint8 and whether there
is a workaround, but otherwise this looks like a good addition to Octave.


    _______________________________________________________

Reply to this item at:

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

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