List Commands Library for 50g

09012017, 11:55 PM
Post: #111




RE: List Commands Library for 50g
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 deduping 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 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 abovementioned 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 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 => 

« Next Oldest  Next Newest »

User(s) browsing this thread: