Blog Post Spinning: Instant Genius Or Just On-Demand Insanity?

Hey There,

NOTE: Since the above is the only line (save these introductory ones) of this repost of one of the few posts I've done here that contains nothing but insane ranting (Reference The original posted response to the demand for me to write a completely nonsense post ...on purpose ;) for the original version. It may or may not be funnier than this one ;), I feel compelled to let you know that this bit of surrealism is a bullet aimed at the heart of article spinning. I suppose it would have been more profound (In an Andy Kaufman'ish sort of way, if I didn't feel the need to explain myself, but he had a much drier sense of humor than I do ;) Enjoy the read :)

And, just in case this next line gets mangled, too:

Cheers!

If you're a lawful reader ( or even a slightly product reader ) of this blog, you haw hit noted that from instance to instance I'll, tongue in cheek, attain reference to, one day, eventually writing a locate that basically says nothing, goes nowhere and ends flat, leaving you opinion same you bought another pet rock. For whatever reason, there is resistless interest in my actually going finished with this and making a rank mimicry of my journal (although I've felt, at whatever times, that I was achieving that modify quite admirably ;) by writing meet much a post. Since I pride myself, somewhat, in doing what I feature I'm going to do (no concern how stupid or harmful ;) today has embellish the day that I locate digits to keyboard and blow discover that post.

PLEASE NOTE: I'm not kidding. While this locate haw be somewhat amusing, you module probably walk away, after reading it, realizing exclusive that you'll never ever get that instance back. Without boost ado, fanfare and/or circumstantial pomp, here comes that post. Please Stop Reading Now if you don't poverty to feature a whatever paragraphs that module ultimately pose no problem, hold null and leave without paying the check. You've been notified. This locate is meaningless. It module also be cursive without emoticons from this saucer on. The whole thing's a joke. I meet can't type that many winks in one post. The last instance I attempted to, my keyboard got rubor and I had to hit it deloused at the Rustler Steak House down the street from my Pet Psychic's favorite Organic Food outlet.

Unix and UNIX are two keywords I same to use a aggregation in locate bodies, and locate titles, for this blog. It goes mainly to the fact that this journal is about lots of things Unix and UNIX related. And, since it's next to impracticable to do beatific SEO with a journal where the content on the front page changes all every day, dropping backwards on those two words (and a whatever choice other ones) helps ready this cyber-rag in Google's goggles. You haw hit noticed that I used them in my denomination today and have, thus far, used the words UNIX and Unix a total of 6 nowadays (3 each) within a relatively short chunk of text. I hit no sense of direction and also can't calculate keyword density on the fly, but, if my offhandedly calculations are correct, I'd feature we're hunting at about a 100% saturation level, at the rattling most.

I'm a huge fan of Solaris and RedHat, which makes it hornlike for me to speech to plants, even though my wife insists that they're listening and I haw actually be serving them grow. Still, when it comes down to a choice between using either UNIX or Unix to rank a particular task, I run to lean toward the wall in the duty with the most stable furniture. I've been studying Feng Shui for whatever instance now, and I crapper honestly tell you that null is where it's supposed to be. One of the underlying principles of that ancient training (or is it meet the exclusive belief that involves heavy lifting?) is the assertion that where you locate things crapper hit a dramatic effect on your quality of life. For instance, if you follow a subfigure in your eye, you module be blind, bleeding, in nonindulgent pain and making a disorderliness of your experience area in no time. Luckily, the color flushed attracts beatific energy. The kind that module help you muster up the strength to either vantage that subfigure backwards discover of your eye or, at the rattling least, locate your @ss in a car that (depending upon the severity of your wound) is either going to modify up in the crisis room parking aggregation or enwrapped around a tree on your neighbors lawn. If you promulgation sufficiency beatific energy, you haw even attract the attention of strangers who module call 911 as presently as they've run discover of video tape.

Fortunately, the resolution to every difficulty is nearly as simple as the difficulty itself. All you requirement to do is follow these 3 simple steps, and you'll be able to troubleshoot whatever UNIX or Unix difficulty that comes your way. This is a tried-and-true method that is virtually 100% guaranteed...

1. Be trusty that you see the language in which the difficulty is existence described to you. More pointless meetings hit been adjourned due to poor act than for whatever other reason. Understanding is key when you're handling with someone who is completely paralyzed by irrational fear. If, after exhausting all options, you find that you still cannot attain whatever headway, pretend to understand. Nodding, squeezing of the lineament between thumb and forefinger and unclear (yet distant) actuation of the eyes, coupled with satisfactory sounds same mmm-hmmm, crapper go a long artefact toward getting you to step 2 as quickly as possible.

2. Email the exclusive programme you hit who, for whatever reason, refuses to answer direct questions via whatever recordable medium. While he (or she) crapper be extremely irritating under most circumstances, you hit an ally in this management-type who module provide you with absolutely bullet-proof @ss-cover if anyone ever comes around asking questions. Just be trusty you send the original email and ready binary copies (at binary locations) of the response requesting that you get unitedly to handle the issue in person at an off-site location.

3. Using the aggregation you've barely gleaned, and the brush off you've cleanly pocketed, during the enforcement of steps 1 and 2, manufacture an incident that trumps both with respect to both immediacy and length-of-engagement. If you hit to get to work on something \"mission-critical\" right away and you strength be going at it for days, without sleep, so that your consort crapper hang on to whatever hope of staunching the flow of imaginary life-blood-cash, your difficulty should be reassigned presently enough.

IMPORTANT NOTE REGARDING STEP 3: Be trusty that your \"emergency\" requires you to be off-site (i.e. discover of the duty and, preferably, discover of the accumulation center. Shoot for a non-extradition country, if possible) in visit to fix it. Maintain act exclusive via pay-phone. Never turn on your machine or your cell phone. Be trusty that everyone understands that they \"are\" talking to you on your consort cell's speaker-phone (even though they aren't) and use a public tangency at the library to occasionally snap a mail finished a VPN connected to your organization's backup network. Make trusty you manually edit the headers meet sufficiency to attain them unclear to a manlike and completely sensible to a mail agent. If you reassert frequency-silence by leaving your cell phone and machine off, you crapper refrain suspicion to a better degree. Even the more paranoid among your masters module be somewhat comforted by the fact that all the systems are intense \"and\" the GPS devices they've weighed you down with aren't indicating where in the world you are. If you possess a car, take a bus. You probably hit Tom-Tom in there or whatever form of LoJack. If at all possible, find a locate in the mountains (near a National Park or Wildlife Preserve) to do your heavy troubleshooting, live off of berries and kill your possess food. If you're reasonably intelligent, after a week or so, you'll never poverty to come back.

That existence said, given Solaris' and RedHat's solidified track records, I think you'll find that, utilizing a comely steam-powered vacuum cleaner, you crapper attain nearly whatever stain countenance worse. If you do null added for the rest of your life, constantly berate yourself for buying white carpets. And don't go easy on your self. Be really mean. You deserve every moment of the sorrow you're going to endure. What were you thinking? That'll inform you to use Linux, when Unix is a perfectly acceptable alternative OS that is also all biodegradable, so you crapper feel crack while you're busy raping and pillaging the surround in whatever other way.

It goes without locution that...

, Mike

---

Discover the Free Ebook that shows you how to make 100% commissions on ClickBank!

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Unique Sorting Of Lists And Lists Of Lists With Perl For Linux Or Unix

Hey There,

Yesterdays post on sorting Perl lists and removing duplicates did end up being a bit heavy at the end, as I feared. I received my fair share of "here's how you can do it better" emails, which (although I'm not trying to do my most succinct and efficient work here) I always appreciate. In all seriousness, I really do enjoy getting different perspectives on methods and practices put up on this blog. I'm always looking to better my own skill-set, so keep the free advice coming. I'll probably devote an entire future post to the suggestions I've gotten regarding this (with attribution to the contributor's, of course) as the myriad means to an end are quite diverse, clever and interesting. And, yes, we do print contrary opinions as well, but they have to be logical arguments or, at the very least, scathing put-downs that make sense within the given context. If you just write us to tell us to go #### ourselves, we may take you up on that (it can get lonely out here in cyberspace ;) but it won't ever end up as a comment attached to a post.

For today, we're going to break down two areas which generated the most response (mostly because, although I tried, the code just wasn't self-explanatory enough). Sometimes it's actually harder to try and explain something you already do by rote than to explain something you're in the process of picking up on yourself. The two examples for today fall into the former category. My blinders made me think that the code I put out would be easily digested, but (after reading a few comments) I agree that perhaps I was a bit presumptuous. But, life goes on and we learn from our mistakes (even if we just keep making them over and over again ;)

The basic questions, and a bit more detailed of a breakdown:

Q. Why the klunky foreach block at the top of the attached code? Shouldn't sorting be simpler?

A. Actually, sorting data is simpler, but, in this case we were dealing with sorting on two levels, which may not have been readily apparent. The @s_perms array that gets returned from the public domain "permute" subroutine actually contains multiple scalar pseudo-lists. That is to say that $s_perms[0] could be equal to "1 3 2 4 5." While this resembles our lists that we want to sort, it is actually just one variable made up of numbers and spaces. So, for each member of the @s_perms array, we did the following:

1. First we split the scalar variable into an actual array, so that "1 3 2 4 5" became @temparray, with values of 0 through 4 ($temparray[0] = 1, $temparray[1] = 3, etc), like so:

@temparray = split(" ", $unsorted);

2. Then, we sorted that newly created array. The reason we sorted each value returned by the "permute" subroutine was so that each value would be in order. When we do it this way (below), every @temparray list ends up with the members, in order, of "1 2 3 4 5." If we had just called a numeric sort ( $a <=> $b ) on @s_perms, it would have sorted all of the individual lists using their initial numeric value as the sort index. To put it more simply, assuming @s_perms contained only 3 scalar values of:

"1 2 3 5 4"
"4 5 3 2 1"
"1 5 4 2 3"

a straight-up sort on @s_perms would generate a sorted list like this (in order, top to bottom):

"1 2 3 5 4" <-- All 3 scalar values ("1 2 3 5 4," "1 5 4 2 3," etc, being considered single entities) are being sorted as individual elements within an array.
"1 5 4 2 3"
"4 5 3 2 1"

Since our Objective states that all permutations of the same lists of values should be considered equal, the straight-up sort wouldn't make it easier (later) to determine if any, or all, of the 3 scalars were representative of unique or duplicate lists. When we break down each scalar value within the @s_perms array and split that scalar into a temporary array (@temparray) and then do the sort on that, only the values in @temparray get sorted. That is to say that "1 2 3 5 4" gets sorted, and then "1 5 4 2 3," etc. This results in our generating a sorted list like this:

"1 2 3 4 5" <-- Each scalar is split into an array with the "@temparray = split(" ", $unsorted);" statement from above and that array is sorted independently of each succeeding or preceding one!
"1 2 3 4 5"
"1 2 3 4 5"

3. Then we get to the step that caused some folks to wonder why it wasn't the first action taken:

@temparray = sort { $a <=> $b } (@temparray);

Now, we're sorting just like we would have in step 2 (if we did it this way), except we're sorting array variables that have already had their "insides" sorted. Having a list of array elements like:

"1 2 3 4 5"
"1 2 3 4 5"
"1 2 3 4 5"

makes it a lot easier to weed out the duplicates later.

4. Then, we add that array (of individually, and universally, sorted arrays) to the right hand side of the @sorted_perms array, which we use further on in the script.

unshift(@sorted_perms, "@temparray");

Simple enough ;) Hopefully, I'm not making this any worse for the folks out there who wrote in ;) Seriously, though, I do hope this explanation helps out at least a little.

The second question was just as valid:

Q. What's with the @unik and @last_unik variables. I understand that you're comparing arrays, but what are you doing in your "elsif" equality test?

A. This is a great question, because, on its face it seems that all we would have to do is check if the two arrays are equal and that would be that. Unfortunately, this practice has one fatal flaw (and, curiously enough, the behaviour is the same if you use the numeric or alpha comparison operators!) The basic test of the "entire array" actually only considers quantity of indices as indicators of uniqueness. For instance, this small script:

#!/usr/bin/perl

@bob = qw (1 2 3 4 5);
@joe = qw (1 3 2 5 4);

if ( @bob == @joe )     {
        print "BOB and JOE are == Equal\n";
}

if ( @bob eq @joe )     {
        print "BOB and JOE are EQ Equal\n";
}

produces this output:

host #./test
BOB and JOE are == Equal
BOB and JOE are EQ Equal

Since the basic equality operators only count indices to compare, I used that as the "outside loop" test. I figured, if the two arrays didn't have the same number of members, they couldn't possibly be equal, and we'd move on to the next loop without doing all the extra work. However, if the index counts match, then we need to check and see if the "content" of the arrays are exactly equal. So, if:

} elsif ( @unik == @last_unik ) {

returns true (both @unik and @last_unik have the same number of members), we'll go check them out index by index. I started out by setting three variables, just for ease of reading and to establish controls.

1. $total = @unik; <-- This populates the $total scalar variable with the length of the @unik array

2. $zero = $nope = 0 < -- This is just simple shorthand for assigning the variables $zero and $nope the value of "0."

3. Then, I iterated through both arrays at the same time (At this point in the program, every array has been sorted, so they should all be "1 2 3 4 5"). This was accomplished by a simple while loop that incremented the $zero variable (which represented the index of the @unik and @last_unik arrays) and compared those index values with each other. If, at any point, an index in @unik didn't match the corresponding index in @last_unik, the variable $nope was set to 1 and the while loop was broken (no sense calculating the rest of the index values, since we just hit a difference and the two arrays can't be identical anymore). Every time the corresponding values matched, the value of $zero was incremented by 1, and the process repeated, until the value of $zero reached the value of $total (the length of the @unik array:

while ( $zero < $total )        {
 if ( "$unik[$zero]" ne "$last_unik[$zero]" )    {
  $nope = 1;
  last;
 }       else    {
  $zero++;
 }
}

4. The block of code following that would only execute if we had found a difference between the two arrays, and the value of $nope was set to 1. This would be an indicator that @unik was a different (unique) array than the previous one and should be printed out. Then (and this shows up more than once), after the value is printed, I set @last_unik to be equal to @unik (Note that the = "assignment" operator is used here, rather than the == "comparative" operator). This sets us up to test the next @unik against @last_unik (which was @unik in the previous iteration) and easily be able to tell if that next array is just more of the same. This is set elsewhere within the larger construct, as well (on a different condition).

if ( $nope )    {
 print "$s_p";
 @last_unik = @unik;
}

5. As a side note for this piece of code, again, it was written to be simple to follow and works on the assumption that we've sorted the individual arrays numerically (see the first question at the beginning of this book ...I mean, post ;) and they are all the same. For instance, if the array @sorted_perms contained @array1, @array2 and @array3, and they were populated like this:

@array1 = "1 2 3"
@array2 = "3 2 1"
@array3 = "1 2 3"

You would not get a return of 2 values ("123" and "321") since we're not maintaining state in any other way. Since array's 1, 2 and 3 are processed in order and different from each other (in order, one after the other), they would all show up as unique (and be printed) in our example. If we wanted to make sure that we only got "123" and "321" back, we'd have to implement another method to double check that we weren't repeating ourselves. Of course, that would add another level of complexity, and I'm trying to keep this as simple as possible, but, since you asked, you can easily avoid duplicate unique values (??? Can those really exist in a sane universe? ;), you can do this most simply (I think), using grep, and Perl hashes, in the right place, like in the pseudo-code below:

foreach $bogus_value (@bogus_array) {
 unless ($seen{$bogus_value}) {
  $seen{$item} = 1;
  unshift(@bogus_array, $bogus_value);
 }
}

and, that would guarantee you that no "duplicate unique" values would appear in your output :)

That's about all I can sneak in at lunch here today ;) Until next time.
Cheers,

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Sorting Perl Lists And Removing Duplicates On Linux Or Unix

Hey there,

This may be the first time I've run a series of posts where the topic was different every step of the way. That's a good thing, because I get just as bored as anyone else reading about the same thing over and over ;) So, following in the footsteps of our posts on Number Pools And Guaranteed Combinations Within Fixed Lists and Perl List Permutations, we'll move straight ahead to the next logical step, which is almost an entirely different subject altogether. I will however, reiterate (repeat again... sorry, one of my idiosyncrasies ;) our Objective in this whole exercise (Skip to the next paragraph if you feel I've done this sentence to death ;) : Given a Number Pool of "x through y," create the maximum possible Fixed List Length variations of our Fixed List that contain some variation of our Guaranteed Combination, without any duplication (i.e. 1, 2, 3 is equal to 2, 3, 1 and would only count as one match), and return the results.

Of course, to revisit the definitions of our key components , please refer back to our previous post on Number Pools

Today, we're going to look a Perl list sorting. In this context, you can actually consider our lists as arrays if you prefer. I'm going to keep calling them lists because, in the end, it will most closely approximate what we will want to manipulate; a fixed list of numbers.

From yesterday's posts on list permutations you can basically understand, even if you didn't run the code, how very many different combinations of 6 numbers there can be, when duplication is not a factor (i.e. 1, 2, 3 is different than 3, 2, 1). In our case, given our Objective, we would want those number lists, in parentheses above, to be considered equal. So how do we go about that?

There are actually quite a number of ways you can go about doing this. They run the gamut from human-readable and computer-intensive to nearly-hieroglyphic and incredibly efficient. Some folks like to dump all their values into hashes and sort it out that way, since the Perl hash function is built to sort keys and values. I'm not against that at all, but feel like it might stray us farther off the path and I want to keep this series of posts somewhat accessible.

My answer is actually a fairly commonly used one, as well. I don't consider myself a Perl expert (or really even a Unix or Linux expert. Like in Eastern philosophy: Even the teacher is ever the student). If I ever do convince myself that I know it all, I'll probably have a fatal seizure from lack-of-interest within moments of my revelation ;)

I like to sort all of my permutations (in this case numerically) first, and then check for duplicates. This makes sense to me, for some reason, and (especially in this case) it can greatly reduce the pressure you feel when dealing with large numbers of numbers. For instance, our 720 permutations are all of the same 6 numbers, so, once they've all been sorted numerically, we're going to have 720 identical lists. We don't even need a computer to tell us what our Objective obliquely defines as a "unique list" in this situation. It's "1, 2, 3, 4, 5."

All of our actions are predicated on the output of the "public domain" code we put out yesterday, which has been revised slightly to suit our purposes (the original just printed out the answers and didn't do any variable assignation or a return) and, yes, I do use my lists as arrays from time to time (we all need time to relax and unshift ;) The "permute" subroutine is called with an array, or list, (@number_seeds) as its only argument (which contains "1, 2, 3, 4, 5"), like:

@s_perms = permute([@number_seeds], []);

Modified code below:

sub permute {
    my @items = @{ $_[0] };
    my @perms = @{ $_[1] };
    unless (@items) {
# LIMITED TO ONE CONTIGUOUS PERMUTATION CHAIN
        @sortperms = join(" ", @perms);
        unshift(@s_perms, "@sortperms" );
    } else {
        my(@newitems,@newperms,$i);
        foreach $i (0 .. $#items) {
            @newitems = @items;
            @newperms = @perms;
            unshift(@newperms, splice(@newitems, $i, 1));
            permute([@newitems], [@newperms]);
        }
    }
return @s_perms;
}

And that's the lesson for today. I've attached code to the end of the post to illustrate the steps of sorting each list in our list of lists and checking for (and removing) duplicate lists from the pool. Note that we don't take into account multiple variable lists, as this won't be germane later (and adds some heft to the scriplet :) I tried to make this as easy to read as possible, so various steps, which could be combined, have been spelled out. If it has the opposite effect and makes things more confusing, I apologize profusely. And let me know! If there's interest, I'd be happy to write about this stuff at a much more granular level :)

Here's the mock output, to save you a screenshot:

host # ./program
1 2 3 4 5

Enjoy!





This work is licensed under a
Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License

#!/usr/bin/perl

#
# program - an unoriginal name for an unoriginal concept ;)
#
# 2008 - Mike Golvach - eggi@comcast.net
#
# Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License
#

foreach $unsorted (@s_perms)     {
        @temparray = split(" ", $unsorted);
        @temparray = sort { $a <=> $b } (@temparray);
        unshift(@sorted_perms, "@temparray");
}
#@sorted_perms = sort { $a <=> $b } (@s_perms);

$unik="0";
$last_unik="0";
foreach $s_p (@sorted_perms) {
        @unik = split(" ", $s_p);
        @unik = sort(@unik);
        if ( $unik == $last_unik )      {
                print "$s_p";
                @last_unik = @unik;
                $last_unik++;
        }       elsif ( @unik == @last_unik )   {
                $total = @unik;
                $zero = $nope = 0;
                while ( $zero < $total )        {
                        if ( "$unik[$zero]" ne "$last_unik[$zero]" )    {
                                $nope = 1;
                                last;
                        }       else    {
                                $zero++;
                        }
                }
                if ( $nope )    {
                        print "$s_p";
                        @last_unik = @unik;
                }
        }       else    {
                print "$s_p";
                @last_unik = @unik;
        }
}

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Lists vs. Strings: Perl List Permutations For Linux Or Unix

Hey there,

I think I promised yesterday that all posts having to deal with Number Pools And Guaranteed Combinations Within Fixed Lists would have that string in their title, but, upon further reflection, it seems like it would make every title waaaay too long, and none of the parts would get indexed correctly, since Google might discard them as duplicate content based on the title tag.

In any event, this post is another small step toward yesterday's objective, along with (hopefully) an understanding of the various processes and steps involved in getting there. These are, indeed, small chunks of information when taken separately, but that is by intent. I'm not trying to insult anyone's intelligence; just keep the playing field even for all concerned ;) If you need to review the definitions of our system, please refer back to yesterday's post on Number Pools and we'll iterate (not reiterate of course, because that would be repeating it again. I'm only repeating it this time... OK, enough with the wordy nit-picking ;)

Today, we're going to look at one of the basics of building a system which can produce our desired end result. That basic building block is known as the permutation of a list, as opposed to an array (or string). Given Perl's definitions, at their basic, a list is static and cannot be modified, while the opposite is true of an array. They look deceptively the same. Most people don't know the difference. I still may not have a fingernail grip on the exact definition and details of the difference, but it hasn't caused me too much heartache ;) And, of course, strings are generally considered scalar variables (single value).

Our objective has been modified (in form, not in nature) to accommodate this change (and I've updated the original post's definitions as well): Given a Number Pool of "x through y," create the maximum possible Fixed List Length variations of our Fixed List that contain some variation of our Guaranteed Combination, without any duplication (i.e. 1, 2, 3 is equal to 2, 3, 1 and would only count as one match), and return the results.

In any event, my sincerest apologies for using string when I meant list. I didn't get a whole lot of complaints about this, which means either most everyone got what I meant or a vast majority of readers believe that Internet democracy will sort me out one way or another (which it has). This is what happens when you write at family gatherings ;)

So, given our Fixed List from yesterday (the numbers that, together, add up to a total of "Fixed List Length" members), we would first be looking for all permutations of that List. The list being composed of "1, 2, 3, 4, 5"

Using the following "public domain" code (meaning I didn't write it, don't accept credit for it, love it, but don't know who to credit it to ;) we can generate all permutations of our Fixed List. This will be the first thing we want to do, because this step needs to be completed before we check for Guaranteed Combinations within those permutations!

#!/usr/bin/perl

permute([1,2,3,4,5], []);

sub permute {
my @items = @{ $_[0] };
my @perms = @{ $_[1] };
unless (@items) {
 print "@perms\n";
} else {
 my(@newitems,@newperms,$i);
 foreach $i (0 .. $#items) {
  @newitems = @items;
  @newperms = @perms;
  unshift(@newperms, splice(@newitems, $i, 1));
  permute([@newitems], [@newperms]);
 }
}
}

This will produce all permutations of the List "1, 2, 3, 4, 5," as such (cropped for space savings):

5 4 3 2 1
4 5 3 2 1
5 3 4 2 1
3 5 4 2 1
4 3 5 2 1
3 4 5 2 1
...

As you can see, given our very simple example (where everything is equal to 5 and all lists and combinations are 5 (or 1, 2, 3, 4, 5), we have a lot of repetition in our output, and part of our stated objective is to create this list "without any duplication (i.e. 1, 2, 3 is equal to 2, 3, 1...)..."

Obviously, although this piece of Perl code will provide us with every possible permutation of the list "1, 2, 3, 4, 5," according to our Objective's definition, they're all equal. As we noted yesterday, the result can only be one list of five numbers, given our standards.

Tomorrow, we'll look at a way to resolve this issue, using a minimal amount of code (and, of course, a lot more of my concentric-circular explanation ;) so that the permutations get whittled down to the one unique list (containing all 5 numbers in our list) and removing all the "technically" different ones, which are essentially all the same list printed out in different order.

Cheers,

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---

Number Pools And Guaranteed Combinations Within Fixed Lists

Hey There,

It's been a while since we've taken any time to look at any formal systems or number systems (all the way back to The M I U Puzzle, so today we're going to kick off a quick beginner post that is, somewhat Linux and Unix independent(although we'll be scripting and using Linux/Unix tools to do this work for us in future posts). It's going to segue into something more complicated in a future post, but, for today, we're just going to lay the groundwork. In fact, the beginnings of this process will seem almost brain-dead simple. Which is okay, because they pretty much are ;)

Our topic for today, and for all the follow-ups, is going to be: Number Pools and Guaranteed Combinations within Fixed Strings.

We'll adhere to the following definitions (Followed by our Objective):

Number Pool: A pool of unique numbers of any given amount spanning any given start and end numeric parameters.

Fixed List: A string of numbers of no more than the total number of numbers in the Number Pool and not containing any duplicate numbers.

Fixed List Length: The number of numbers in our Fixed List.

Guaranteed Combination: A combination of unique numbers (restricted to the members of the Fixed List we've defined) with a minimum member count of 1 and a maximum member count of the total number of numbers in our Fixed String.

Guaranteed Combination Length: The number of numbers in our Guaranteed Combination.

Our Objective: Given a Number Pool of "x through y," create the maximum possible Fixed List Length variations of our Fixed List that contain some variation of our Guaranteed Combination, without any duplication (i.e. 1, 2, 3 is equal to 2, 3, 1 and would only count as one match), and return the results.

Hopefully, that didn't sound too convoluted or complicated. It's not. Here's what we'll do to prove that very quickly.

1. Our Number Pool for today will be defined as: 1-5 (i.e. 1, 2, 3, 4, 5).
2. Our Fixed List will be: 1, 2, 3, 4, 5
3. This gives us a Fixed List Length of 5.
4. Our Guaranteed Combination, will be: 1, 2, 3, 4, 5
5. This gives us a Guaranteed Combination Length of 5.

So, the question before us is: Given a Number Pool of "1, 2, 3, 4, 5," what are the maximum possible variations of the 5 digit Fixed List "1, 2, 3, 4, 5" that we can create which will contain our Guaranteed Combination, without any duplication? (and, remember, this post is just to get you started thinking about the theory we'll put into practice later)

Simple deduction will lead you to this answer, since there can be only one correct answer (Which, in a sense, is true of larger systems, as well) and our variables are equal. Our result would be 1 variation:

1, 2, 3, 4, 5 <-- Note that the list 5, 4, 2, 1, 3 would be equal and would also be a correct answer, but would not count as an additional variation since it is made up of numbers duplicated from the original variation of 1, 2, 3, 4, 5.

Think about this for a while. It's a good exercise for your head :) In future posts we'll be looking at different variable expansions and the number theory behind generating these sort of lists (For example, a Number Pool of "1 through 99" with a Fixed String of "1, 3, 4, 6, 8, 9, 13, 17, 18, 20, 33, 47, 56, 68, 77, 87, 93" and a Guaranteed Combination of "1, 4, 6, 47, 68" - There will be a lot more strings to produce given these circumstances, which is where Linux or Unix scripting, as mentioned above, will help tremendously). Of course, we'll attack each individual part separately before combining them all into one equation (which will actually be somewhat simpler, but I guess that's a matter of opinion ;)

Cheers,

, Mike

---

Please note that this blog accepts comments via email only. See our Mission And Policy Statement for further details.

---