What they need to do is write a small little program that does this and assures everything is random and distributed.

If I can do it (http://elmo2.ath.cx/gen/) then surely someone at FIRST or a volenteer could.

Greg

PLEASE FIX!!
 

Ok folks. At GLR, Team 68 was paired with the same team twice, and played against that team twice. This happened with two teams!, so, in all 6 of our matches, we saw the same two robots 8 times. Whaaa??? One would think that programming this wouldnt be terriblly difficult.

More iderations and an "if then" statemenet or something (spare me the correct terms, im not a programmer)

Oh well. I heard that it was being looked into at GLR for the midwest and grandrapids regionals.

Greg. I ran the applet and typed in the info of 40 teams 10 matches... It paused for about 10 min luckly i had it in the background. I made a similar prog in java but had it output a 'debug' screen filled with a table that showed who played who. I thought your program was the solution until I ran into the divisable by 4 issue. Regionals don't always have a multiple of 4 number of teams. I'd love to see the source code if your willing to share.

I know the divisible by 4 is annoying, I haven't spent the time to work around it.

The zip file I attatched earlier will output info as it works, the applet works on only one thread so it appears to lock up (in truth only the gui is locking up, it is working). My program really has no checking and will continue attempting to find a impossible match list. If you feel it's taking to long try lowering the target or min times between matches (and raising the number of times to play with others).

Like I said, its not a good solution but my program will work if you give it possible constraints and enough time to do its thing.

You don't want to see my source as it is really really poorly written :)

Greg

Being the scoring operator at Great Lakes this past weekend, and therefore the one telling the system to generate the matches, I am well aware of this problem. It stems from how the system attempts to maximize the time between matches for a given team(the algorithim used is meant specifically for this.) Unfortunately, this causes a less than perfect distribution, as many have already mentioned. I am currently working on a system which will be submitted to the proper people at FIRST(having worked extensively with the FIRST scoring systems the last few years, I know who these people are) for preliminary testing at the West Michigan Regional(if not sooner), which will do the following:

-ensure that no team has the same alliance partner more than once in 99% of situations(the strange "overlap match" between one set of matches and the next is the only exception).

-Attempt to allow at least 5 matches between 2 matches that any given team competes in(may be changed, the code is really ugly for this part)

For those of you who have seen my discription of the pairings code used for OCCRA this past year, this may all look vaguely familiar...that's because it's based off of the same code. Because of this, my repeat opponent checking logic still stands...there is none. My feeling is that unless both alliance members in the opposing alliance are the same(which is 99% impossible using my pairings code, due to the ally checking), you do not truly have a "repeated opponent" However, the system uses a random number generator, re-initialized at every launch, so if you don't like the # of repeated single team opponents, just run it again and get a different set of values. I'm actually working on final testing and FileMaker integration now, so we'll see what happens...

---UPDATE---
On the first trial run with FileMaker Integration, The statistics I got were as follows:

Max Times paired w/ same team: 1.0
Max Non Unique Allies: 0
Avg Non Unique Allies: 0
Count of Teams with 3 or more ally repeats:0

Max times opposing same team: 2
Max # Non Unique Opponents: 2.0
Avg # Non Unique Opponents: 0.7

Min # Between Matches: 6.0
Avg # Between Matches: 13.7
Max # Between Matches: 33.0

What do you think?

Whats that data show? How many teams? How many rounds? How many rounds total? Otherwise its hard to know if 13.7 rounds is a long or short break. At some regionals teams play 10+ times while at larger ones its 6 matches. And since there always seams to be about 100 matches played then thats an average break of 10 and 13.33 respectively.

I realized sometime overnight that I had forgotten to include this information, so here it is:

# of Teams: 68
Matches Per Team: 6
Total Matches: 102

Sounds very good.

Hopefully FIRST will decide to use your program (and I see no reason for the not to).

Greg

FIRST now has the source as well as a high-level description of its workings, and one of their scoring developers is going to take a look at it probably tomorrow to see if there is a nice way to either tie my program into filemaker, or rewrite the logic directly in FileMaker's scripting language. He seemed very interested in finding a way to use it...it's just a matter now of making it easy to use for those scoring operators who don't want or need to know how everything works under the hood...

Match List Stunk
 

I must say, our match list really sucked (sorry for the harsh words). We had 249 in 3 matches, 560 in 3 matches (we were partners in 2 matches), and 494 in 2 matches. I'm not saying that these teams sucked, but what I mean is that it would be nice to get a little more variety. I would sacrifice a little unpredictability in time-between-matches to have a little more variety in the matchups. I don't care for it when there are 68 teams at a regional and I see one team in half our matches and another team in another half of our matches.

So, pleeeeease Nate, get your program to work and use it for West Michigan. If it works well there, use it at nationals.

-Chris

Don't forget Houston, the LSR. Use it there, too. Although, if you do the math, with 31 teams, the highest number of matches a team could have without repeating one of the three other teams is ten, and we'll probably play at least twelve each, so I'm expecting a lot of repeats.

My team, 782, was partnered up with Buzz twice. Not that it really matters that much.

Wildstang had the same team twice in a row in Midwest.

As my programming teacher would say, "don't ever depend on a computer to give you a random number because it cannot pick a random number, it's just making it look random." That is unless you just take that # out so it will never be used again or that any team # can only be picked x times and they get pulled out. To pick random #'s a computer usually runs through a "list" of #'s with set bounds to how many #'s to run or what #'s to run. If you catch it too fast or there is a glitch in the program it can be the same #. I truely think that they should have done it with lottery balls or a hat because that is way more random.

We had to play team 494 the martians (probably the best team there) 3 times! We beat them once (even with a disabled partner :)

at midwest, we found that we had to be partners with some teams, and then go against them the next round. This happened about 4 times. It was frustrating especially when we'd help teams with robot problems that would be almost done when the match started, but couldn't show up or do anything, And then the next round they were working fine. More importantly, because of the schedule I didn't get to see half of the teams compete, including our ellimination partners team 217. So I hope it a little bit more random and West Michigan.