Hi all,
been working for quite some time on a Java version of the Archon. I
want to implement the optimal seating that spans across the whole
playing field and I have now finally gotten it to work for 16 and 25+
players, so that if you choose the optimal seating randomization
variant it will make sure that two people do not meet each other twice
in a tournament (this is for a tournament with up to three qualifying
rounds).
Howeber, for a tournament with say 12 players, or 17 players (and
three qualifying rounds), someone will always meet someone else twice,
simply due to the fact that you can only move so many players between
the rounds in order to avoid this. So I am trying to figure out some
kind of formula that allows me to know when I need to allow for
meeting conflicts without continuing to try to do my optimization.
Does anyone have any idea on how I should proceed?
Thanks,
Archie
[ quoted text not captured ]
This may not be helpful, but why not just use the seating chart given in the
Archon? Why the need to "further" optimize the chart?
Kevin M., Prince of Las Vegas
"Know your enemy, and know yourself; in one-thousand battles
you shall never be in peril." -- Sun Tzu, *The Art of War*
"Contentment... Complacency... Catastrophe!" -- Joseph Chevalier
Please visit VTESville daily! http://vtesville.myminicity.com/
Las Vegas NAQ 2009! http://members.cox.net/vtesinlv/
[ quoted text not captured ]> Las Vegas NAQ 2009!http://members.cox.net/vtesinlv/- Dölj citerad text -
>
> - Visa citerad text -
Because the current chart only goes up to a certain amount of player
(albeit a large amount). The optimal seating is (unless it has been
changed) also grouped to include batches of 50 people, and you won't
meet people outside your batch, my optimized seating seats players
across the whole playing field. I also include the option to have true
randomization (meaning only the prey/predator rule is in effect) which
is supported by the tournament rules (not sure anyone ever plays with
that but it still supported).
Archie
[ quoted text not captured ]
As far as "won't be at the same table":
It's impossible to do with a three-table tournament and three rounds,
which rules out 15 or less players.
It's also impossible to do with four tables if any of the tables has
>4 people, which rules out 17-20 - unless you force the 20 to be five
4-man tables.
> Archie
-John Flournoy
[ quoted text not captured ]> -John Flournoy- Dölj citerad text ->
> - Visa citerad text -
Yes, hence my first post. I am hoping someone will help me find a
simple formula for knowing this, so I can allow for conflicts.
Archie
[ quoted text not captured ]
I think the biggest benefit to an automated "optimal" seating chart comes from
the ability to quickly handle drops and adds.
And to handle marathon tournaments (4+F or 5+F or more).
The rest is probably insufficient (on its own) to justify the effort.
Anyway, to the original question: use a cost function. Then choose the seating
with the lowest cost (or: stop looking when improvements the cost level off).
Choose costs for violations of the optimal criteria based on their relative
priority.
On Feb 25, 2:59 pm, carne...@gmail.com wrote:
> On Feb 25, 2:07 pm, Archibald Zimonyi <a...@aranzo.netg.se> wrote:
>
>
>
> > Hi all,
>
> > been working for quite some time on a Java version of the Archon. I
> > want to implement the optimal seating that spans across the whole
> > playing field and I have now finally gotten it to work for 16 and 25+
> > players, so that if you choose the optimal seating randomization
> > variant it will make sure that two people do not meet each other twice
> > in a tournament (this is for a tournament with up to three qualifying
> > rounds).
Additionally, since you it working for 25+ players, you by default
have it working for all cases 50 and above; you can group them into
optimized batches of 25+ and swap between the batches as you so
desire .
For instance, in a 50-man tournament, you create two batches of 25.
After the first round, swap roughly 1/3 of the people between batches
while keeping their distribution order the same (i.e swapping the
'first person table A' from one batch with 'first person table A' from
the second.) And then after round two swap a different third. And so
forth for larger sizes and batches.
25-49 should be doable as a single batch easily enough.
So:
1-15: impossible.
16: solved
17-20: impossible (possible exception: 20 if you insist on 4-man
tables)
21-24: unsolved
25+: solved (or at least easily solvable based on what you've already
got)
> > Archie
-John Flournoy
[ quoted text not captured ]
There's not really a need for a formula; unless you have <15 or 16-20,
there isn't a need for any conflicts.
The other trick is making sure that the distribution you use doesn't
put people at a 4-person table instead of a 5-person more often than
it has to.
> Archie
-John Flournoy
[ quoted text not captured ]> >> Las Vegas NAQ 2009!http://members.cox.net/vtesinlv/-Dölj citerad text ->
> >> - Visa citerad text -
> > Because the current chart only goes up to a certain amount of player
> > (albeit a large amount). The optimal seating is (unless it has been
> > changed) also grouped to include batches of 50 people, and you won't
> > meet people outside your batch, my optimized seating seats players
> > across the whole playing field. I also include the option to have true
> > randomization (meaning only the prey/predator rule is in effect) which
> > is supported by the tournament rules (not sure anyone ever plays with
> > that but it still supported).
>
> I think the biggest benefit to an automated "optimal" seating chart comes from
> the ability to quickly handle drops and adds.
>
> And to handle marathon tournaments (4+F or 5+F or more).
>
> The rest is probably insufficient (on its own) to justify the effort.
>
> Anyway, to the original question: use a cost function. Then choose the seating
> with the lowest cost (or: stop looking when improvements the cost level off).
> Choose costs for violations of the optimal criteria based on their relative> priority.- Dölj citerad text ->
> - Visa citerad text -
Yes, adding removing players will be a function and a benefit for
larger tournaments.
The others are merely done for my own coding pleasure (which is also
why I have been working on this for the last three-four years).
Thanks, will look into the cost function and how to implement that.
Archie
[ quoted text not captured ]
No, 1-15 and 17-20 is not impossible. I know I have to allow conflicts
here since otherwise my tool would be useless, I want to know just how
many conflicts depending on number of players and rounds. The same
goes for 21-24.
Also, 20 players has to be four table tournament according to the
tournament rules (as many 5-player tables as possible).
Archie
[ quoted text not captured ]
In fact, in some ways that's the key issue - which is more important?
Keeping the equity between 4-man and 5-man tables, or not seeing the
same opponent twice? The two may not be mutually achievable.
> > Archie
-John Flournoy
[ quoted text not captured ]
I have no idea how to fashion formulas to automatically cover variable
numbers of rounds and players, honestly.
21-24 players in a 3-round setting doesn't have to have any conflicts,
btw, unless you care about evening out appearances at 4 and 5-man
tables (and might not even then). It's not hard to just manually
determine a possible non-conflicting seating for each of those four
cases and work from there.
> Also, 20 players has to be four table tournament according to the
> tournament rules (as many 5-player tables as possible).
Yep, just being completist by noting that 20 is doable with 5 tables.
It's obviously got to have conflicts with only 4.
> Archie
-John Flournoy
[ quoted text not captured ]
I prefer to handle one problem at a time. Right now I just want a
tournament with 17 players to actually end (instead of currently
trying to come up with a zero conflict solution forever).
LSJ also mentioned players should not (in his opinion) have to be
seated at position 1 more then once either, also something that I plan
on adding later on as an option.
Archie
On Feb 25, 11:25 pm, Archibald Zimonyi <a...@aranzo.netg.se> wrote:
> LSJ also mentioned players should not (in his opinion) have to be
> seated at position 1 more then once either, also something that I plan
> on adding later on as an option.
>
> Archie
Here are the complete seating rules revisited. Unless Scott has
changed them within the last few years.
1. No pair of players repeat their predator-prey relationship. This is
mandatory, by the VEKN rules.
2. No pair of players share a table through all three rounds, when
possible.
3. Available VPs are equitably distributed.
4. No pair of players share a table more often than necessary.
5. A player doesn't sit in the fifth seat more than once.
6. No pair of players repeat the same relative position[*], when
possible.
7. A player doesn't play in the same seat position, if possible.
8. Starting transfers are equitably distributed. [NOAL]
9. No pair of players repeat the same relative position group[^], when
possible.
* relative position: prey, predator, cross-table (4-player table),
grand-prey, grand-predator (5-player table)
^ relative position group: adjacent or non-adjacent
[ quoted text not captured ]
No those look like the ones Scott gave me. Need to throw out my
current formula and start from scratch again then. See you in four
more years :)
Archie
LSJ schrieb:
[ quoted text not captured ]
Also note that any Archon not implemented in Excel could offer a proper
export format (e.g XML) that could be automatically processed by a White
Wolf rating site. Importing Excel files with multiple tabs in anything
not Microsoft is a pain.
--
If playing against Cock all you need to
remember is: Don´t get caught by Cock.
[ quoted text not captured ]> >>> Las Vegas NAQ 2009!http://members.cox.net/vtesinlv/-Dölj citerad text ->
> >>> - Visa citerad text -
> >> Because the current chart only goes up to a certain amount of player
> >> (albeit a large amount). The optimal seating is (unless it has been
> >> changed) also grouped to include batches of 50 people, and you won't
> >> meet people outside your batch, my optimized seating seats players
> >> across the whole playing field. I also include the option to have true
> >> randomization (meaning only the prey/predator rule is in effect) which
> >> is supported by the tournament rules (not sure anyone ever plays with
> >> that but it still supported).
>
> > I think the biggest benefit to an automated "optimal" seating chart
> > comes from the ability to quickly handle drops and adds.
>
> > And to handle marathon tournaments (4+F or 5+F or more).
>
> > The rest is probably insufficient (on its own) to justify the effort.
>
> Also note that any Archon not implemented in Excel could offer a proper
> export format (e.g XML) that could be automatically processed by a White
> Wolf rating site. Importing Excel files with multiple tabs in anything
> not Microsoft is a pain.
>
> --
> If playing against Cock all you need to
> remember is: Don´t get caught by Cock.
Of course. I am planning to include a lot of nice features (one for
example is my hope that organizers need only enter VEKN number and can
then fill in by searching player registry for name/city).
As LSJ pointed out, dropping/adding players between rounds is a huge
plus.
As you point out, having a standardized format for exporting
tournament results would be a huge help to organizers too (and
probably WW as well).
Archie