Quote:
Originally Posted by Jared341
2) In principle, this works. However, think of every combination of <N1 = Number of Teams> x <N2 = Desired Matches Per Team>. Depending on the event (district, regional, division), N1 could be anywhere between 24 and 100+. N2 could be anywhere between 8 and 13. Add in that different events (for various reasons) may also want different schedule parameters (to trade off "randomness" against repeat opponents, min/mean/max time between each team's matches, etc.) and you would need a pretty large high-dimensional table to store all of the possibilities.
|
I wasn't aware that events were allowed to play with the parameters of the schedule, that changes things. However assuming FIRST were to standardize the parameters then the size of the table is at most 100 (24-123) x 6 (8-13) = 600 schedules. Each schedule is at most 267 matches (123 x 13 / 6), each of which has 6 bytes of information for a total of 1.6Kb of data. Add formatting and metadata and we're still not above 10kb... For every possible schedule! That would be incredibly easy to transfer and traverse. And it would allow us to put more processing power into determining the optimal schedule for each possibility.