Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add random_connected matching function #26

Merged
merged 1 commit into from
Jun 18, 2023
Merged

Add random_connected matching function #26

merged 1 commit into from
Jun 18, 2023

Conversation

boykovdn
Copy link
Collaborator

Can now create more exciting matching, where each team battles at least N other teams.

@phinate
Copy link
Collaborator

phinate commented Jun 18, 2023

Just before merging this: can you remind me in which context this is going to be most useful? I think probably in the context of the BTModel right (@philswatton?)

@boykovdn
Copy link
Collaborator Author

I think we wanted a sparse alternative to the all-vs-all scenario for performance reasons. Using min spanning tree created a star network every time, and the random spanning tree seemed to create very linear matchups where some teams are very far away from each other and most teams only play two matches. So we through it might be nice to be able to set as a parameter how many matches you want each team to play minimally and add that as random edges on top of a spanning tree. We add edges to the spanning tree to ensure there are no disconnected components.

Not sure if this had a specific application to the BT model @philswatton will know more.

@phinate
Copy link
Collaborator

phinate commented Jun 18, 2023

That makes perfect sense -- indeed, it's nice to have something non-exhaustive that plays out most battles.

So if I understand correctly, teams play at least N matches in this paradigm, and at most play every other team. There's maybe some smart way to choose N such that the estimate of fitness stays the same within a certain tolerance (similar to what @eddableheath was exploring), but that could mean that some teams could get away with playing a small number of weak teams and getting a very inflated fitness (plus we'd have to calculate fitness after every battle...)

This is great though -- thank you for coding it up :)

@phinate phinate merged commit 8615531 into main Jun 18, 2023
@phinate phinate deleted the new_matching branch June 18, 2023 14:30
@philswatton
Copy link
Collaborator

Yes - the idea here is that instead of scaling matches exponentially with the number of teams, we can scale them linearly by setting a minimum number of matches per team (e.g., 10, 20).

The BT model comes in because with a lower number of matches, I'd expect the performance of the win percentages fitness function to start degrading (because it doesn't take into account the difficulty of beating that opponent in particular), whereas the BT model does explicitly take this into account (so facing mainly weak teams wouldn't be that impressive).

I don't think I get the point re calculating fitness after every battle, this shouldn't be necessary? But I think I'm missing something!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants