Match Pairings not random (not even close!)
 

Did any of the other regionals have really messed up qualifying pairings? At St. Louis, we had one team on the opposing alliance 4 times! Also, we had one of our matches duplicated (exact alliances)!

I'm sure that this led to some nuances in the qualifying points, for a number of reasons.

If the opposing alliance had a robot (or two) that could not get over the ramp, the scores tended to be very low as the totes got bulldozed out of scoring position. Plus, with no ramp points for the losing alliance, the 2x adders didn't amount to much. In many ways, you were better off where the teams were good enough to get over the ramp and make some points.

We were fortunate enough to qualify well, but it's really hard to figure out if we did that based on skill, or just dumb luck! I hope that they get the random number generator restarted before the next round of regionals. I feel sorry for some of the teams that had frustrating qualifying because of the non-random pairings. Everyone should have 8 different matches to give them an opportunity to show their stuff!

At BAE I think they did an excellent job gettign us random parings and spreading out the matches as much as they could, we had matches 11, 22, 30, 40, 50, 60, 70, 80, 90, and 100 You really cant get much more spread out than that over two days with 44 teams competeing, as for pairings, there was problay one or two teams that we went aganist twice but that was it

i saw that brr and grr were allied together twice on saturday at the Ohio regional. kinda like nationals last year when we didn't see 50 of the teams in our division on the feild with us

At VCU, we had 3 identical matches. The same robots were on the same teams. To top it off, we wire tied our auto. switch in the right position because until elimination rounds, we were on the red alliance, on the right hand side. If that is random pairings, I need to go buy a lottery ticket...;)

I think Techno Jays at Buckeye were probably pretty sick of being our opponents after 3 matches!?

My experience is that the matches are too random. In the past I've had 2 matches back to back on the same day. Another day we didn't have any in the morning all were in the afternoon. The program is propobly a simple spreadsheet that only makes sure teams have the same number of matches. They could add more checks to insure duplicate matches don't occur, teams have at least 2 match breaks. It's all how much effort FIRST puts into the schedule. As for being Red all day, does that really matter? Its normally worse in smaller regionals because the lack of a pool to draw from. The larger the pool the less problems the schedules seem to have.

At BAE, our actual matches were very random, but during practice, we ended up being pared with Buzz every time.

At SLR (55 or 56 teams) we were partnered with 1215 twice in one day. We were opposed by 1005 twice, 1098 twice, and 770 four times!

-Joel

Actually, it really is not as easy to pare up the matches as you think. While i don't know how first does it, I talked with the person that made matches for a local robotics competition, and it's pretty hard to make them.

If you logically think about it, it's very hard to make a match list.

First: Are you going to assign matches to teams, or teams to matches. (IE: Are you going to loop through the team list and assign teams to matches, or are you going to loop through the empty match list and pull teams to fill that match)

Second: Now you have to insure that teams aren't going to play all back to back, but rather spread out though all the matches. (IE: For team fill: Pick match # between 1-10. Pick match # between 11-20 (and make sure that if the match is 11, that the last one wasn't 10). For match fill: Go through the first 10 matches, and pull numbers only once from a team list. Make sure that none of the teams that were in match 10 play in match 11)

Third: Attempt to prevent teams from playing with another team more than once. (IE: Have different alliance partners each time)

Forth: Make sure that the script doesn't time-out or not find a solution that passes all requirements.


As you can see... it's not as easy as you may think from a programming viewpoint as you may think.

<sort of off topic>Making lists like this really is quite hard. (Even to programmers, I first looked at making match lists and thought "This isn't hard", but once you get down to doing it... it's a pain in the butt. I've thought about it a few times, but really don't even want to know how something as large as my high school makes the class schedules. - There are sooo many constraints</>

at manchester in THREE matches we were paired with a partener we had allready been allied with previously. and in one match were against a team we had allready played against as well.

AT BAE we were paired with the same three robots in 6 out of our 10 matches. It does make it easy to startegy plan in second match but we did not even see 6 of the top ten finishers!

we had the same partner 2 of our practice sessions and we went up against the killer bees our last 2 matches.

It would have been nice to have variety but it wasn't that big of a deal.

Its just the way things turned out and we dealt with it.

Random number Generator V1.0
Starting random engine....
Buffering for output...
Random number stream:
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9
9

-- End Output


The problem with random numbers is you never know.
Greg

it was actually 3 times & we had to play against them once. 2 out of our first 3 matches were against the same 2 teams. FIRST had better fix this fast or there will be alot of unhappy people. & BTW It was us that 461 was paired with for practice & we only played 1 team in the the top 10. The eventual #1 seed. We did beat them in one of the 2 times we played them.

The problem that FIRST has is that their top priority is that teams have enough time between matches (approx. 1 hour) to repair and refine their robots. The problem is that since your next match is in about an hour, and all the teams you played with have their next match in about an hour, odds are pretty high that you will see at least one of them again in your next match. If FIRST actually went through and made sure that pairings were never repeated, the schedule would actually be less random.

Think of it this way: If you flipped a coin ten times, but wanted to make sure that you never had two heads or two tails in a row, there are only two possible combinations (hththththt and ththththth). However, if you had no checks on the results, there are 1024 possible combinations. Obviously, the first scenerio is much less random.

this is nothing new...
 

This "non-randomness" has been a perennial problem with FIRST teams for years. The competition software apparently automatically generates the pairings. With small data sets the randomness goes away (10 rounds- 50 teams).

Of course doing it by hand is a nightmare. Believe me- I've done it using both techniques. Even worse is trying to keep any team from playing matches too close together.

Perhaps a good off season project is for someone to make the perfect system without assigning team numbers and present it to FIRST. Make a number of possibilities for 40-41-42 teams etc- so FIRST can use whatever system is applicable to the regional based on attendance.

Of course someone will always have a problem with it...

WC:cool:

It happened to us with 1000. A good team to be matched up with. A tough team to be matched up against.

St Louis is the first regional we have attended in the past four years where we had such non-random pairings. I know many other teams had similar pairings at STL.

In the past, either someone hand-paired or set the flags in the s/w differently. I'd be curious to find out why it worked in teh past but not this year, since this kind of program shouldn't change from year to year.

Part of the problem with non-random pairings is that you only get to interact with a small segment field. There are competitive issues as well. But they are not as major as the interaction issue.

There were other technical difficulties as well in STL, especially with the scoring program. I suspect that in the first weekend of regionals that all these bugs cropped up and there simply wasn't enough manpower to deal with everything.

It really depends. I was at the VCU regional, and some teams had problems with the psuedo-randomness of the match pairings, while others did not. Our team happened to be against team 401 twice, but that is all, and we didn't find anything wrong with that.

Also, this does come up every year. One of our mentors knows the guy who does the match pairings for a few of the regionals, and he explained it this way: they do the pairings the night before competition for security reasons (they don't want anything leaked), and that doesn't give them enough time to change anything drastically. Also, due to their system setup, it is impossible to individually switch teams by hand (and even if they did, the issue of just how many repeats are allowed, and who to switch with comes up).

Overall, it's an imperfect system. Any system will be. The people behind it are a bunch of die-hard FIRST volunteers, who are doing their best to create a fun playing enviornment. If you do have problems with match pairings, I only ask you to bring it up in a polite way, and don't expect them to change things this year.

Good luck at all your regionals everybody!
Stephen

we also had similar pairings, we were on the field with a team 4 times,another 3 times and others twice. it wasnt that big of a deal to us, yes it did hurt our rank though, but i really would have liked to be able to play with and against a wider variety of robots.

Ok folks, here is the deal.

If we put a lottery machine next to the field and generate matches that way, you will probably get the exact same thing, and the only good side is there will be less complain to us about pairing not being random. The bad side is, the lottery machine will probably make it even worse.

We tried the best we can to generate match list. On Thursday night, I set at the scoring computer for about an hour, generating match lists after match lists, using most of the 11 methods included with the scoring methods, and the best we could get is have two team who will get paired with at least 1 same partner for 7 times.

Now, it could be that Sacramento is a small regional of 27, and a lot of teams are bound to face each other again, but still, that's just the way it is. I had to maneually swap some teams, and it worked out fine. Teams were fairly happy about the matches (if not, you can complain to me, and I will apologize for it).

The thing is, FIRST tried the best they can to make the match generator. There are 11 methods of generating "random" matches, and the score keeper work for a long time to keep trying and trying to make it good. But the fact of the matter is, we work all day from 7am to 5pm to get the matches working, and more than 2 addition hour beyond that schedule is simply unresonable. I even heard St. Louis score keeper had to stay until 3am in the morning to get it working. We just can't check the list number by number after working more than 10 hours straight.


But don't get me wrong, I understand the frustration for teams as well. I've been on a team myself. It's just that given the limited resources and time, this is the best we can do so far. The list is as random as it will get, it's just that the numbers don't look that way.

If you want to create your own match generator, feel free to do it, but don't even bother submitting it to FIRST unless you have done more than 1000 trails, and all of them looks "random" and makes you happy. But then again, that's not really random itself. Being "random" means some of the time it's not going to look random.

not too bad...
 

As a participant of the Sacramento regional i would say that the matches were well done and the pairings were fairly random. We played against one team 3 times and that was it. My only complaint was that there was very little time between some of the matches (less than 3 rounds). But with 18 total matches in 2 days one cant really expect to have a long break. I Think that first is did a fine job witht he Sac regional.

Team #538 also found their "random" pairings to be highly questionable. We had 4 matches with 906, were partnered twice with 1208 and 1005, and faced many other repetitions that I can't remember. While I was complaining about this in the pit, a mentor from #525 leaned his head over the wall saying that they faced the same problem.

We went to the Kennedy Space Center (FL) regional for the past two years and never faced this kind of craziness before. Maybe we just got (un?)lucky.

I was at the VCU regional and we had 2 identical matches. We also saw some teams several times. The most concerning unchanging thing for us was our placement on the playing field. We were always placed in position C1 or D1. That means we were always starting with our robot to our left and always entering the playing field onto the red carpet. We noticed in practice that different carpet gave us different results in autonomous mode. It was unnerving having to have our first test of autonomous mode from a new position occur during the finals.

...On the other hand, I was extremely happy to have had a chance to be in the finals. Thanks for picking us Synergy! If any of the rest of you get a chance to be allies with team 975, congratulations! Those guys are truely professional teammates!

Eric

Yup, our first and last practice matches, we were up against 343, then the next day our first qualifying match was exactly set up the same as our first practice match. We later faced the same alliance as before with 343.

We did face 122 twice, but that seemed normal since the other two teams were different.

And yes, we stayed red the whole time. Now this is nice for not having to change lights, but this cuts down who you could possibly be paired with and paired against in half. I'd loved to have been paired with 343 for once instead of facing them for 2 practice matches and 2 qualifying matches....

Its effect on qualifying rounds...
 

As previously stated, it seems the St Louis regional didn't use a very random randomizing system. We either played with or against team 755 in 5 of our 8 matches. There were also several other teams we played with repeatedly.

The lack of randomization can perhaps be unfair and limiting to teams in qualifying rounds. Some teams are not always capable of creating high scores, thus often leading to one-sided, low-scoring games (leaving relatively low QPs).

At VCU we had two pairs of identical matches:

Match 11
Blue 510 1054
Red 977 587

Match 65
Blue 510 1054
Red 977 587

Match 24
Blue 611 405
Red 339 587

Match 78
Blue 611 405
Red 339 587

I understand that 339 had three of these pairs.

I can't complain, because the matches with 977 were very good scores that helped get us a 6th seed. We later chose 977 and 448 for an alliance that got us into the finals. I'm sure that some teams were not as lucky in their duplicate match partners.

The match pairings can't be completely random, but I think that exact duplicate matches should be avoided if at all possible.

Teams 977 and 448: Thank you. You guys are awesome.

Teams 384, 388, and 395: You guys are a little too awesome. Good luck at Championships.

I have actually spent a fair amount of time working on this very problem. There are tremendous improvements that FIRST could make to their existing system, but my guess is they don't have the resources. Check out this thread for some more detailed discussion on this subject.

Basically we aren't the first ones to come across this problem. Check out this link for some work that has been done for bridge tournaments. Maybe FIRST could hire this guy to adapt his program for use in FIRST?

FIRST could do MUCH better if had the resources to put on this issue.

It was said earlier that first could not change the configurations because their system wouldn't allow it. Did anyone look at the schedule and get the impression that it was just an MS Access report??

Eric

Well...considering that they don't use MS Access anymore, I don't think it's an MS Access report ;)

It has been redone this year using filemaker.

It seems like there are some rather large problems with the pairings in some of the regionals. It seems like the best way to get matches random, though, is to get all the matches put together (in no particular order) and arrange them to have a fairly good spacing between them.

Given what I have heard from some teams, anything would be better than the system currently in place.

it seems like they always had a good system in the past. They probably just need to work the bugs out of their filemaker system.

It will depending on the score keeper.

Some of them will be willing to sit there for 2 hours looking over a list of over 94 matches and with 4 teams per match, and checking each of the 376 numbers just to make sure the matches are fair... Some of them will probably generate the list in half an hour, look at the statistics and try to make sure the matches aren't horribly similar...

All I can say is, good luck. I am sure they did the best they can to make good matches for you.

Also, I was messing around with the scoring program a little bit last night, and generated a match list with teams having at most 2 similar matches with same teams instead of the outrageous 6 or 7 we got at Sacramento the night before. It would've been so cool using that match list instead, but it just got to appear here instead of during one of the 30 tries at Sacramento.

And also, thanks for the critism about this problem... FIRST is aware of it, and are trying to fix it from year to year. I think it's time for constructive critism, and tell FIRST something that can help them fix the problem, instead of just saying "anything would be better than the system currently in place".

Ok, been putting some thoughts into this.

How about, we generate a match list ahead of time, and making sure it have the most non-similar matches you can ever get?

We would do one for each number of teams, ranging from 27 to 50. With an existing match list, here is what we can do:

The match list will be for hypothetical teams from 1 to 27 or 1 to 50, etc.
Then teams at the regional are randomly assigned to one of the numbers between 1 to 27 or 1 to 50.

So, when the teams are assigned a number, they will be sure the matches are most non-similar, while having enough time in between. You will have the effect of playing with random teams. The only thing missing is that the top 4 teams and the last 4 teams might be paired together.

But then again, you won't know the ranking before the matches starts, so that won't be a problem anyway. The matches isn't going to change when people start playing.

I really like that idea Ken L.

If someone(s) going to put a lot of time into making a list, they should only have to do it once. Also, you really aren't taking away the "randomness" of the matches, because when you put all the error checking into the list, you allready have removed pure randomness.

Of course, different regionals would have different numbers of total matches. How one would deal with that, I don't know. Either way, I think, end the end, it would be a better system. The "key" list could be made as soon as the total number of matches is known, which could be weeks before. However, nothing could leak out because team numbers would not be assigned until the night before.

Keep up the great job FIRST! :D

Why worry about the number when you can just make a match list for each number? So, ranging from 27 to 50, that's about 24 list. Given time ahead of competition, that can easily be done.

The randomness will still works because you are randomly picking teams to be one of the teams in the existing match list.

Anyone else have any input? I really think this will work, and I am willing to suggest this to FIRST.

we played against team 1090 3-4 times, and with them once. This does not strike me as random. Also, I feel we had bad luck with that random thinger, we only had two or three matches with alliance partners who were real good, and a few where they didn't work at all.

I'd like to see the whole random thing redone. We didn't qual, but I'm not really bitter, especially after our last match (110 @ Stl) where we dominated two teams at once . . . 1090(again) and 877 (#6 or 7 ranked).

It was a good match, our partner protected our stack (and failed, although it was a great effort) and we got the boxes. After we knocked middle boxes down 877 and 1090 tried to come up the ramp, but we manhandled them both. the final score was disappointing (73-3), especially because we had agreed to let all four robots on top at the end . . but only our alliance robots could get there. Still, when you've won half your matches and are still out of the running, a sweep feels good. If only we could have managed to convince 877 to pick us as an alliance partner after that . . . . . . . . . .

ok Ken...

I'm not sure if we're thinking the same thing. If you could expalin your idea a little better, it might help. Here's what I think your trying to say:

You're going to make a match list just how you do now. The only difference is that instead of using actual team numbers, you'll use the numbers 1-x (x being the total number of teams at the competition) You can do this weeks before, and have plenty of time to have lots of people hand tweek each match for plenty of seperation and to rarely ever see a team twice.

Now, the night before the regional, you'll randomly assign each team attending one of the 1-x numbers. Then that team assigned their 1-x number will play wherever that number is. This way, the entire world could see the match list, but until teams are assigned numbers, no one would know who's palying who.

Is this what you're trying say?

Exactly, Jack.

Let's say a very simple example of 8 teams.

A,B,C,D,E,F,G,H

and it's a 1 vs 1 game.

A vs B, C vs D, E vs F, G vs H

then the next round, in order to keep it random and while having enough time in between matches, you would make the next rounds:

A vs C, B vs D, E vs G, F vs H.

If we are only doing 8 teams, with 8 qualifying matches total, that would be the way to do it. We have no ideas what 8 teams will be there, but at least we have a match list done already. It doesn't have to be all that random at all. From now on, for this situation, we wll always use A vs B, C vs D, E vs F, G vs H, A vs C, B vs D, E vs G, F vs H for our match list.

Now, at the competition, we look at the 8 teams, 1,2,3,4,5,6,7,8. It could be very easily be A =1, B=2, C=3, and so on, and that will make a match list of:

1 vs 2, 3 vs 4, 5 vs 6, 7 vs 8, 1 vs 3, 2 vs 4, 5 vs 7, 6 vs 8

Or we can do it A = 8, B = 1, C = 7, D = 2, E = 6, F = 3, G = 5, H = 4, and have a match list of:

8vs1, 7vs2, 6vs3, 5vs4, 8vs7, 1vs2, 6vs5, 3vs4.

By randomly assigning the teams 1,2,3,4,5,6,7,8 to A,B,C,D,E,F,G,H, you can create a lot of different combinations of teams in matches, while making sure the teams get enough break in between.

The ABCDEFGH list will be done ahead of time, and the only work need to be done at regional is matching 12345678 to ABCDEFGH. This will make sure the ABCDEFGH list is as non-similar as possible, while the random matching between the two list will make the matches as random as possible each time.

Make sense?

I looked into this the other day, and made a simple prgram that would take X amount of teams and randomly create matches...

I said 40 teams for 110 matches because that was a general average of the regionals. Since both were variables they can be changed. Then to insure teams had a break I created a queue. Team are randomly choosen from the available list then sent to a match and the queue. The queue was 16 teams so when the 17th got assigned the 1st was sent back into the available list. This insures teams are never double assigned and they have a 4 match break. I never got to the point of checking for duplicate matches. It works well until teams reach the max matches then they are permanently removes from the available teams. Well a few teams would have fewer matches and at the end 3 or 4 teams would play twice in the same match and back to back matches to make up. I tied insuring the majority of teams played 3 matches before lunch then 4 more before the end of teh first day. Still near the end there were always these oddball teams. The point is with all the checks its impossible for a computer to figure this out all by itself without a rediculous program.

KenL suggested the lists are premade and that seems the best idea. There is probobly some pattern that can be applied to any list to create the matches. However some teams will play together twice if there are more matches than teams.

I am a student on team 648, we were at the St. Louis Regional this past weekend. We were paired against team 16 (the all-feared Baxter Bomb Squad) 3 times! And twice against team 45, the TechnoKats. This was definately not ramdom. Because of this, we won 0 matches and placed 54 out of 55.

Thank You,

Budda648

Ken L... Great Idea! (Yep, we're on the same page)

I would definatly recommend it to FIRST. The problem with the old system is that you wanted to make the list the night before so the list wouldn't leak out. Now, you can make the list weeks in avdance, tweek it, and have much less to do during the actual competition. (Which I'm sure you would love :D )

I can't really see a single con.

Great Job FIRST & Keep it up!

A few years ago (2001 I believe), the scoring system actually did use a template-based system, and while I don't believe the templates were hand-tweaked, there were a few downfalls to it:

• The particular algorithim used did not like lower team counts(i.e. any post season event)
• It required maintaining lists not only for a specific number of teams, but for various numbers of matches per team.
• The particular template format used wasn't exactly user-friendly for tweaking.

Nothing major, true, but at the same time, considering the suggestion includes hand-tweaking the template tables, there would be a large number of man-hours put into analyzing each generated template and optimizing it.

As I believe Ken has mentioned, there are 11 different pairings formulas available in the system this year. The trick is to find the system which works best for the particular number of teams and matches at any given event. I hope to, at the events I will be working at, have the opportunity to test every one of these pairing scenarios to see which works out the best for that particular event.

And in regards to the comment made about modifying the match table, it is not done for a few reasons:

• With the scoring system this year, the functions within filemaker that you have access to are determined based on a password entered at launch time. Therefore, without the proper password(which is not given to system operators at a given event), you do not even have access to the match table directly to perform editing.
• As has been mentioned, the match list is not generated until Thursday night. This is done to prevent the problem of a team not showing up, and them still being on the schedule. With that small amount of time, it does not really allow for any time to seriously look over the match schedule, and still have time to get it copied for distribution to the teams.
• Due to the lack of time to manually look over the schedule, the only real way(short of the match statistics given by the scoring system after match generation) to know of any discrepancies is to have the teams point them out. This becomes a logistical nightmare if you have to modify matches after the schedules are released, then have to either announce changes or reprint matches.

Pregenerated list with random team # assignments would solve the problem of a team not showing up also, you just go to the list with one less team. If First would generate a master list, with up to 100 teams playing however many matches the work would only have to be done once. After that the regional or Nationals would just reach in, get the correct number of teams and matches...and have a computer randomly assign a number to each team. The point is....the work would only have to be done a single time, it would be tough, but they could use it forever.

Haven't read any of the aboves posts but a few... however, what I can say was we were paired again 56 three (or four) times and again 25 and 384 twice each... It was somewhat frustrating see other teams who were playing literally two vs zero matches and just getting freebie points. I'm going to work on an algorithm for it soon.

I agree that they aren't random.

Here is team 639's match list at annapolis:

match # - alliance partner - opponent/opponent

4 - 375 - 272/56
18 - 87 - 384/348
30 - 449 - 56/25
45 - 134 - 384/56
58 - 348 - 25/1027
72 - 484 - 204/768
84 - 596 - 384/1027

Now don't get me wrong, I'm not mad about this or anything - I just don't think it is random. At least we weren't paired with the same team as an alliance partner more then once, but I would've liked to play against more teams on the opposing alliance.

We played with:
384 - 3 times
56 - 3 times
25 - 2 times
1025 - 2 times
348 - 2 times

In only 7 matches. Random? Probably not. I think a better way needs to be found. My team would have gladly played 2 matches closer together or further apart to help mix things up. Its not that I don't mind playing with the same team more then twice, but with so many teams to possibly play with it's sad to only get to play with a few of them.

Greg

Gee- I'm hurt. I thought you liked us.....

it WAS good to have the time between matches to make repairs (AKA- rebuild and modify drill gearboxes) But you are right- randomness wasn't always there. For example, Team 25 has yet to face or play alongside MOE in season competition! (YET!) We always look forward to that.


(PS- great machine Code Red- way up on our list)

WC :cool:

I really like this back and forth game....
 

http://www.chiefdelphi.com/forums/sh...threadid=19464

And.. I hope they don't use the same system to choose divisions down in Texas. I like the teams we have played with and against in NYC this weekend, but I don't want all of them to "randomly" end up in our division in Texas.. I want variety man!!!

If teams are expected to be able to program an autonomous mode for a robot that was built in 6 weeks, then it should be fair to expect that a program could be written to help alleviate our concerns with these "non-random" pairings. Most teams do not want purely random pairings. They simply want an "IF" statement that checks to see if teams have already played previously in the same match.

While I understand that constraints like time between matches exist, there are some ways around this. All teams break for lunch on Friday as well as the break between Friday night and qualifying rounds Saturday morning. Could there be 3 groupings of teams (Fri AM, Fri PM and Sat PM) where the programs assigns matches based on the groups? This would allow time between matches, but also "shuffle the deck" so to speak?

I know that we were frustrated seeing the same teams directly before our matches or in our matches at GLR.

The problem with programming the algorithm isn't the requirements but makeing sure they always work.

Number of matches a team will play
Number of matches a team will have to repair/recover
Making sure a team will only play another team once

We'll start by making a program that randomly assigns teams to matches. Making sure teams have 3 matches off. Well we first run into a problem because some teams will finish there matches quickly. Near the final matches teams start to ineligable because there done witha ll there matches. This means some teams will have to play again quickly in the end. At the very end if a team has very few matches then it may twice in the same match.

Then check to see if teams duplicate matches. What happens near the end if a team has to play a team again. You'd have to back up and reassign matches over and over until it worked out perfectly.

The point is computers aren't intuative. They do exactly what you tell them. RNG(Random number generators) don't evenly pump out numbers either. Try a simple excel spreadsheet. For example if i told a RNG to call a number between 1 and 10 until one of the numbers was called 10 times the results could look like.
1 5
2 6
3 3
4 8
5 6
6 9
7 3
8 10
9 2
10 7

The point is the fist 90 matches would be fine but the last 20 or so would start to look weird. Some teams may nto play at all while others play match after match without a break. Teams will play teams for a second or third time. The amount of team who have completed there matches will increase so the available pool of teams will decrease quickly and this is what causes errors.

Instead of complaining figure it out. Many people have suggested making charts that list matches for regionals between 35 and 70 teams then FIRST could assign each team to a number.

Be glad that you play the same people twice instead of playing matches back to back like what used to happen.

we were against the same team 3 times in a row(team 696), but ironically our team was picked to be on their alliance for the playoffs, which was cool. but yes, we were against team 696 3 times, our sister school 989, twice and allianced with 898 twice. 3 or 4 matches our alliance parters either got knocked over, broken during autonomus, or didnt even show to the match (team 64 was having some major problems). so our bot had to go 2v1 for 3 or 4 matches, which made our matches low scoring, and all but one we lost. this made our rank very low (28th), but since we had a good, reliable robot, we were selected in the alliance selections. Our sister school, Palo Verde, 989, had great alliance teams during the qual rounds, which allowed them to get all the way up to 13th place, and be selected in the alliance selections. In AZ, we commonly had just HALF AN HOUR between matches, not the Hour one user was talking about. something is up with the selecitions, i dont know what. but i do think it is luck. we were 38th seed in LA last year, but when we went to Nationals, we were 5th seed and highest rookie - and 989 had some great luck in AZ this year when we went to that regional. so who knows, better luck next time.

-dave

2003 AZ Semifinalist w/ 696, 222
2003 AZ Xerox Creativity Award
2002 Highest Rookie Seed (5th seed) - Einstein Div. Championships

In Cleveland we played Team # 494 3 times, and this past week we were blue every time. We also have noticed that we never play against teams with a number lower than 100.

I used this as an excuse to learn java :)

Attatched is a program that will use brute force to randomly generate a matchlist based on constraints you enter.

To run it download the zip file, extract it to a diectory.

Open a console window, cd to that directory and type "java Generator"

The program should execute, follow the instructions and enter info when prompted.

After it has all the info it needs It will start generating match lists. It will try one possible route, if it runs into a dead end (no more possible matches), and all teams haven't played the required number of matches, it gives up and tries again (without any input from you).

Please save all your work before running this, It probably isn't stable (though since it's being executed by the Java VM it shouldn't crash anything- with windows you never know).

The time the program takes to find an acceptable match list depends on the constraints you give it at the beginning. If you tell it to find a list that would be near impossible to generate by hand, expect to wait a long time. If you wish to stop the program while it's in the middle of execution try ctrl-c (or force close it or whatever).

This program is provided for the entertainment value of all of you :) don't expect it to be stable, and don't rely on it to work as advertized. That said, feel free to let me know of any bugs or errors in the program (or general questions/comments).

Greg

Heh, I was too lazy to complete mine.

Good job Greg. It seems I didn't have to debug it with you for 10 hours before it ran on Windows :)

Random pairings - Yes - but flawed
 

At Great Lakes several of us older teams made it known very strongly that their system of pairing for seeding was indeed a poor system and needs a lot of work ( we were being nice ).

We were assurred that this will be corrected before the next regional..... we will see.

This is not a new complaint, why has it not been fixed already?

We must all express our concern over this problem if it still exists in the next regional.

Let your voices be heard! FIRST is always willing to improve.

If anyone has a good system they can use, send it to them, however, I think it has to be compatable with File Maker pro.

Here's an applet version:
http://24.24.28.120/gen/

Much easier to use.

Greg

We were against team #6 three times down in UCF. It was interesting tho b/c the first two their robot could not move, but the third it was working fine, we won all three however, but it was interesting to keep going over and scouting how well they were coming along w/ their bot.

Team 86 went up against Team 79 3 times in the qualifying rounds!

We didn't get to be partners until the finals!


And I always hate that pair of matches that everyone seems to get where you're playing a match and they're making the "final call" for your next match. It always seems to happen when something breaks, too.

Well, I for one, am very-very disappointed at this stuff.

We played with 470 four (4) times. Two against and two with. I like team 470, but common, we never played Hotbot, Huskies, and many other teams. On average we probably played against/with 10 different teams. I, for one, view this as unacceptable. When you have 68 different teams, and if all didn't show up, i'm sure you would of at least have 60 different teams. Some teams had "easy" schedules, while others had "difficult" schedules. Playing somebody 4-5-6 times kinda wears out and you know their strategy/they know your strategy. I can't see why they just didn't create a whole random "picker" and just exclude out who you already played. I know this has to work many ways with the time and all, but when you start to call teams 10 minutes before the start of a match, i don't see how that becomes a factor. I, for one, am going to take a stab and say that this is the saddest GLR that I have went to. When we went to Pittsburgh, it was beautiful. I don't remember playing any other team more than once, except for 2 times. This new method may not be "big-number friendly" but than just exclude it and create a new one for big scoring. Heck - pull numbers out of a hat! I think FIRST could of done better than what they have...

I'm going to agree with Matt on this. Do something like pin-the-tail-on-the-donkey even...I mean, com'on. I've watched a few matches, and I've heard the announcements, "140, and their partners, 210" like 5x in like, 30 minutes. It's about as rediculous as saying CD isn't the biggest team fanbased website dealing with FIRST.

Also, like what Matt said, you soon know their strategies, so it isn't evenly fair. Team 470 was a great team, both as allies and opponents, but we both knew the persons next move. No offense to you guys, but hey...

Even if you ask teams [not fair, but hey, another idea]....it might balance the universe some.

GLR wasn't all exciting as Pitts., but I still had fun.

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.