List Commands Library for 50g

[DavidM]

(09-01-2017 05:29 AM)pier4r Wrote:  I am not sure you checked it but I'd like to know if you would have done the program here (that is using your library a lot) http://www.hpmuseum.org/forum/thread-892...l#pid78250 differently.
...
I was not able to devise a way to create permutations already "sorted" somehow. If I would be able to do that, I could quit in the middle of the process with the right element.

Well, I had seen Gerald's posts (both the even- and the odd-digit ones) and hoped to spend more time trying them out after working through some other projects. So I've actually been trying to avoid looking at how other folks have approached the problem, at least until I could put more thought into it.

Believe it or not, there is actually a pattern to the output of both DOCOMB and DOPERM. Combinations are "chosen" in a different order than permutations, though. I'll explain that further in a separate post. First, an observation about using these commands for this kind of problem: while there are similarities between these sequences and permutations of the digits in question, the actual permutations needed don't line up in a convenient way (as you have found). That's because the ordinal sequence doesn't have all of the "permutation groups" lumped together in a contiguous range. They are intermingled.

While it should be possible to "permute" most of the needed numbers in the sequence, the process would be somewhat messy and you'd end up having to combine the output of multiple permutations with other numbers and re-sort them to get them into the order defined by the sequence. For this reason, I wouldn't have used those commands for this kind of situation. You'd effectively have to create a lot of permutations, add in the missing numbers, sort the output, then determine which value is indexed at the needed position.

As an example, consider the following simplified variant of using permutations to obtain a sequence. In this version, the sequence is simply all two-digit integers that contain the digits 0-9. For simplicity, I'll include 2-digit numbers that start with "0" in this example.

It shouldn't take too long to realize that there should be a total of 100 numbers in this sequence (00-99). Approaching this from a permutation standpoint, the "low hanging fruit" would be to start with { 0 1 2 3 4 5 6 7 8 9 } and permuting all combinations of 2 digits. So how close does that get us to the solution? Fortunately we don't have to guess -- 10 2 PERM tells us how many "groups" should result from a set of 10 digits chosen 2 at a time. The answer of course is 90, which implies that there are 10 other numbers in the sequence that need to be included. I bet you already know which numbers weren't included, and hopefully this starts to show why this approach is "messy". In this two-digit example, you'd have to add in all of the "repeated digit" numbers (00, 11, 22, etc.), then sort all of the results to put them in order. When you increase the number of digits to 3, the "missing" numbers get even more complicated.

That's a long way to say why I wouldn't approach these sequences using permutations, but hopefully answers your question.