This year's algorithm is a tremendous improvement over the previous years IMHO. I have
read up on it and downloaded it to test(I recommend reading it before posting in this thread). I agree with how it approaches the problems, and love how it is customizable from the command line.
The most important factor in evaluating a schedule, at least in my opinion, is paring uniformity. Here is my grading for the 3 schedules that it generated for my teams:
FLR #365: A Philly #365: C Philly #1495: B
Making broad judgments about the algorithm based only on 3 team schedules at 2 event is flawed because it is a minuscule sample size. However, I think I can provide some analysis. The big problem with 365's Philly schedule is the series of 4 matches (in a row) in which we were with/against 357 (1 with, 2 against). 486 was also involved in back to back matches in this series in a home and home aspect (with one match against the next). This series (or cycle) suggests to me that the algorithm was having trouble maintaining maintaining paring uniformity around the minimum match separation constraint.
I think the default minimum match separation was higher than optimal for Philly. In the 3 schedules, the lowest match separation was 4 at FLR and 5 at Philly so I guess that was the minimum. My guess is that minimum match separation is set to
Code:
# of teams / 6 (round down) - 2
since FLR had 40 teams and Philly had 44 (42 would yield exactly 5).
I would be willing to sacrifice some match separation for better match uniformity. At events the size of FLR and Philly, I personally would be willing to go for a minimum match separation of 3. The software already gives the scorekeepers the option to specify a minimum match separation (although I don't think many scorekeepers do), but I think the way the program computes a default match separation needs some tuning for the next revision (even it is just subtracting 1).
What does everyone else think about the tradeoff between pairing uniformity and minimum match separation?
Quote:
Originally Posted by Knippschild
I was a scorekeeper for the Philadelphia Regional. I was present when the match schedule was generated (by the lead scorekeeper).
The FMS (the event management software) uses a very complicated algorithm to generate a completely RANDOM schedule. When FMS calculates who should be paired with whom, and who should be pitted against whom, it has no knowledge of the team's "big name"ship nor of that team's standings at other regionals.
|
Since volunteers from both 357 and 365 were present when a schedule that called for them to face each other 3 times was generated, I think we can all lay the "algorithm paired big names theory" to rest (not that anyone has been talking about that lately)