View Single Post
  #37   Spotlight this post!  
Unread 24-03-2003, 00:36
Unsung FIRST Hero
Nate Smith Nate Smith is offline
FRC Key Volunteer Trainer
AKA: CrazyNate
no team
 
Join Date: Jun 2001
Rookie Year: 1998
Location: Old Town, Maine
Posts: 1,029
Nate Smith is a splendid one to beholdNate Smith is a splendid one to beholdNate Smith is a splendid one to beholdNate Smith is a splendid one to beholdNate Smith is a splendid one to beholdNate Smith is a splendid one to beholdNate Smith is a splendid one to beholdNate Smith is a splendid one to behold
Send a message via AIM to Nate Smith Send a message via Yahoo to Nate Smith
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?
__________________
Nate Smith
nsmith@smythsoft.com
12 seasons, 4 teams, and more time logged behind the scorekeeper's table than I care to remember...
returning for 2011? only time will tell...

Last edited by Nate Smith : 24-03-2003 at 00:41.
Reply With Quote