List Commands Library for 50g

[DavidM]

OK, thanks for the explanation. I think I understand what you are asking now, though I'm afraid my answer is that there isn't a way to have DOPERM output the permutations in the order you're seeking. Attempting to generate the "missing" numbers by permuting lists with duplicated digits would require de-duping as well as sorting. Adding that to the user program argument might be possible with judicious use of POS, but I would think that this is just not a very effective way to attempt to generate a sequence out of multiple permutations.

It's really good that you asked this, though, because it caused me to find a minor bug in the combination algorithm. It was producing all the combinations OK, just not in the originally intended order that I meant for it to use. I hadn't actually noticed that the order wasn't as intended until I started putting together this response and noticed that the order of combinations wasn't what I expected.

Here's a bit more detail on how things are (now) ordered:

For permutations where all of the list elements are "chosen", the output will be in ascending lexicographical order iff the input list is already in ascending order. In other words, if you do something like

Code:

{ 1 2 3 4 } 4 \<< NL\->I \>> DOPERM

you will end up with output which is also sorted in order:

Code:

{ 1234 1243 1324 1342 1423 1432 2134 2143 2314 2341 2413 2431
3124 3142 3214 3241 3412 3421 4123 4132 4213 4231 4312 4321 }

This is due to the internal method that DOPERM uses to "step" through the permutations. While the code doesn't care about the contents of each element, its position in the original list does matter. It's those original position indexes that are actually being sequenced in lexicographical order, not the contents of the elements.

Now that I've fixed the above-mentioned bug, DOCOMB works in a similar fashion, except it does so regardless of how many elements are specified for the combinations. If you check any of the previous releases, however, you'll see that it didn't work that way before. It was intended to, though. I just hadn't noticed it until you prompted me to look!

Where the lexicographical ordering stops holding, however, is when you specify anything less than the total number of elements for a permutation (eg. { 1 2 3 4 } 3 \<<NL\->I \>> DOPERM). This is due to the fact that there are two inherent loops in DOPERM. They can be thought of as follows:

Code:

for each combination of n list elements
    for each permutation of the current combination
        pass the permutation to the user program

This results in a series of combinations which will themselves be ordered, but the aggregate list will no longer be in order as a whole. It's easier to see this in the output than it is to describe it in words (I've inserted line breaks to make the combinations more obvious). Notice that each combination is still ordered, even while the complete list isn't:

Code:

{ 1 2 3 4 } 3 \<< NL\->I \>> DOPERM =>

{ 123 132 213 231 312 321 
124 142 214 241 412 421 
134 143 314 341 413 431 
234 243 324 342 423 432 }