Suggestion to improve the alliance choosing program

[Bongle]

I crunched numbers on this in 2006 based on 2 weeks of regionals, and here's an image that breaks down scores by 'average alliance number'. Average alliance number was the average of the 3 team numbers that made it up. Note that rookies this year were about 1700+, so a team with an average alliance number higher than that was probably all rookies.

There is definitely some correlation between team number and scores, but it is a fairly weak correlation, and more importantly, there is a LOT of variation in each group. There are rookies who can dominate regionals (2056 in 2007), and there are rookies who can barely get their robot to move. However, there are also older teams like this.

http://www.chiefdelphi.com/forums/at...1&d=1142127063

Edit: Going through all my old statistics threads is fun.

Here's another relevant one. Given two alliances, find their average alliance numbers (AAN1 and AAN2). The x-axis on this graph is the difference between opposing alliance's AANs. If a team like (1114, 1503, 1680) faced (25, 48, 71), then the difference would be something like 1200ish. This graph shows the win rate for the higher-numbered alliance.

Basically, it says that in 2006, if your AANs differed by 1200, then the team with the higher number had a 20% win rate.
http://www.chiefdelphi.com/forums/at...8&d=1142707377

[Rick TYler]

Originally Posted by Bongle

I crunched numbers on this in 2006 based on 2 weeks of regionals, and here's an image that breaks down scores by 'average alliance number'.

Time to go back and increase your data set size, add 2007 and 2008 data, and include a Z-axis with number of teams in each band. Good work!

[Kimberly]

You guys are overlooking something. There's another reason it's beneficial to not have rookie teams on the same alliance. As rookies, we're learning about all aspects of FIRST. We learn the most from experienced teams. It seems to me the mentoring aspect FIRST promotes throughout the build phase, would be appropriate for the competition phase too. On an alliance with 1 rookie team, there are 2 experienced teams to offer help, guidance, strategy, etc. I don't see a down side to this.

While it's certainly possible for a rookie team to outperform many experienced teams, I think it's still in the best interest of the organization overall for rookie teams to get the benefit of what more experienced teams can teach them during that first year. The more experienced alliance partners a rookie team has, the more information it receives on how to be even better next year.

[EricH]

Originally Posted by Kimberly

You guys are overlooking something. There's another reason it's beneficial to not have rookie teams on the same alliance. As rookies, we're learning about all aspects of FIRST. We learn the most from experienced teams. It seems to me the mentoring aspect FIRST promotes throughout the build phase, would be appropriate for the competition phase too. On an alliance with 1 rookie team, there are 2 experienced teams to offer help, guidance, strategy, etc. I don't see a down side to this.

While it's certainly possible for a rookie team to outperform many experienced teams, I think it's still in the best interest of the organization overall for rookie teams to get the benefit of what more experienced teams can teach them during that first year. The more experienced alliance partners a rookie team has, the more information it receives on how to be even better next year.

I don't see how that will help. Remember, FIRST is not about the competition or the robots; it's about the people.

Also, I can think of at least one veteran team off the top of my head that could use some on-field mentoring themselves. They aren't exactly in a position to give advice. You wouldn't know it to look at their number--and the number is what the algorithm uses.

Personally, I'd rather see the return of the design books.

[Dr Theta]

I am unsure as to how something like this would work for some of the younger regionals as well, I mean look at Minnesota this year. Over half of the field is rookie teams.

[Kimberly]

Ok, let me explain it this way: If a rookie team were on 10 alliances with 20 different experienced teams, that's 20 sets of data. The rookie team can decide for itself which advice is useful and which is not, but the more times the same advice is given, the more likely it is to be valid. More information is better than less.

I also am well aware it's not about the competition and winning, which is exactly why I'm suggesting the rookie teams be paired with 2 experienced teams during the competition. If I were promoting a better winning strategy, I'd suggest teams be seeded by individual performance, but I personally don't care about that, except to the extent of keeping track of our individual performance so we know how our design and strategy worked.

If the algorithm were changed to include the fewest pairings of rookie teams possible, and to balance the rookie distribution between the competing alliances, it wouldn't matter what percentage rookies were at the competition. It would only mean there wouldn't be alliances where experienced teams were competing against inexperienced.

[EricH]

Originally Posted by Kimberly

If the algorithm were changed to include the fewest pairings of rookie teams possible, and to balance the rookie distribution between the competing alliances, it wouldn't matter what percentage rookies were at the competition. It would only mean there wouldn't be alliances where experienced teams were competing against inexperienced.

I don't know how easy that would be to implement for next year. (It's too late for this year.) I think it won't be that easy.

Take a look at the 2007 match lists, if you can find any. (The Blue Alliance probably has them.) You will see almost exactly that situation. The hard part will be keeping the other teams from facing each other more than once or twice. Last year's algorithm was the most hated in FRC history. So you want the "third tier" to be made up only of rookies and only one other tier. That can't be easy to do. If you think it is, then I invite you to come up with an algorithm and submit it to FIRST for their use.