Muckturnier

News 17.05–01.09.2020

Muckturnier 3.4.0 out now!

So, wie es derzeit aussieht, wird es leider wohl in naher Zukunft kein Muckturnier geben. Aber irgendwann wird Corona überstanden sein. Und die Entwicklung ist weitergegangen, deswegen gibt es jetzt – Corona hin oder her – ein neues Release :-)

Die neue Version bringt neben zahlreichen Bugfixes vor allem neue Features: U. a. gibt es jetzt ein vernünftiges Konzept für die Auslosung direkt bei der Anmeldung, es werden verschiedene Spielstandzettel unterstützt, das Auffinden von Eingabefehlern ist jetzt deutlich einfacher und die Suchfunktion wurde weiter verbessert.

Im Einzelnen:

Auslosung direkt bei der Anmeldung

Das Konzept für die Auslosung direkt bei der Anmeldung wurde kürzlich schon unter dem Titel Technology Preview: Auslosung bei der Anmeldung vorgestellt. Der Einstellungen-Dialog wurde noch ein bisschen weiterentwickelt und sieht jetzt so aus:

Dialog für die Einstellungen der Auslosung

Hier möchte ich insbesondere auf die Vorteile eingehen, die man durch die Auslosung bei der Anmeldung hat:

Automatische Auswahl in der 1. Runde und für einzelne Spieler

Wenn das Programm weiß, wer wo sitzt, dann kann schon die erste Runde schnell und einfach eingegeben werden: Man einfach wählt die Tischnummer aus, und die Paare bzw. Spieler werden automatisch ergänzt. Nach wie vor geht es natürlich auch, eines der Paare auszuwählen; alles Übrige wird dann automatisch ergänzt. Bisher war das erst ab Runde 2 möglich, da man die Auslosung erst über die Eingabe der Ergebnisse der 1. Runde überhaupt erfuhr.

Neu in Version 3.4 ist weiterhin, dass die automatische Paar- bzw. Tischauswahl jetzt auch für Turniere mit einzelnen Spielern zur Verfügung steht.

Die Möglichkeit, eine Auslosung (manuell) einzugeben und für die 1. Runde bei Feste-Paare-Turnieren zu nutzen, brachte schon die Version 3.3. Jetzt kann aber von der Auslosung weiter profitiert werden:

Optionen für die automatische Auswahl

Die automatische Auswahl wurde in zwei Parameter aufgeteilt. Zum einen „Auswahl laut Auslosung“, und zum anderen „Paar 2 rückt pro Runde weiter“ (beides zu aktivieren bzw. deaktivieren im Menü unter dem „Einstellungen“-Knopf auf der Spielstandseite).

Die „Auswahl laut Auslosung“ greift auf die Auslosung zurück, die auf der Anmeldeseite eingegeben wurde, und zwar unabhängig von der offenen Runde. Das ermöglicht eine Neuauslosung pro Runde, egal, ob man mit festen Paaren oder mit einzelnen Spielern spielt.

Ist zusätzlich die Option „Paar 2 rückt pro Runde weiter“ aktiviert, dann wird nur in der 1. Runde auf die Auslosung auf der Anmeldeseite zurückgegriffen, ab der 2. dann auf die Ergebnisse der letzten Runde (wobei, wie bisher auch, Paar 1 immer sitzen bleibt und Paar 2 immer einen Tisch weiterrückt). Auch diese Option ist jetzt unabhängig davon verfügbar, ob man mit festen Paaren oder einzelnen Spielern spielt.

Das Aussetzen der automatischen Auswahl, damit man auch von der Auslosung bzw. der eigentlich richtigen Position laut der letzten Runde abweichende Ergebnisse eingeben kann, ist jetzt über den Knopf mit dem Autoselect-Zauberstab-Icon rechts neben der Spielstandeingabe möglich. Der ist jetzt da, wo bisher die Option „Paare bzw. Tischnummer automatisch auswählen“ war.

Vertikale Spielstandzettel

Inspiriert durch das dieses Jahr abgehaltene Muckturnier der SPD Konradsreuth (das sind übrigens wirklich hartnäckige EDV-Verweigerer!), bei dem Basti Söllner und ich nur wegen ein paar Toren nicht mit auf dem Siegertreppchen standen(!), bringt das neue Release jetzt Unterstützung für eine weitere Variante von Spielstandzetteln.

Für gewöhnlich wird beim Mucken von links nach rechts aufgeschrieben, Paar 1 oben und Paar 2 unten. Einen Beispiel-Spielstandzettel mit diesem Layout gibt es nach wie vor unter Material. Für diese Variante des Aufschreibens habe ich damals auch die Eingabemaske der Ergebnisse-Seite gestaltet.

Nun wird aber – wie ich jetzt weiß – mitunter (und eben auch von der SPD Konradsreuth) ein Spielstandzettel verwendet, bei dem Paar 1 links und Paar 2 rechts stehen, und die Bobbl von oben nach unten aufgeschrieben werden. Wenn man so einen „vertikalen“ Spielstandzettel in die „horizontale“ Eingabemaske des Muckturnier-Programms eingeben will, bekommt man einen Knoten im Hirn und Eingabefehler sind vorprogrammiert. Evtl. hielt diese Tatsache sogar den einen oder anderen bisher davon ab, das Muckturnier-Programm überhaupt zu benutzen!

Da ich natürlich ein möglichst breites Spektrum an Muckturnier-Varianten abdecken will (und das auch kein allzu großes Problem war), bringt Version 3.4 jetzt eine neue Auswahlmöglichkeit mit. Diese kann beim Anlegen des Turniers unter der neuen Seite „Ergebniseingabe“ ausgewählt (und natürlich auch als generelle Vorlage gespeichert) werden. Außerdem kann man das Layout des Eingabezettels auch noch im laufenden Betrieb ändern:

Unter dem neuen „Einstellungen“-Knopf (wo vorher nur die einzelne Checkbox „Eingabe ohne Tischnummern“ war) versteckt sich jetzt ein Menü:

„Einstellungen“-Menü der Ergebnisse-Seite

Da kann man dann zwischen dem altbekannten „horizontalen“ Layout

„Horizontaler“ Eingabedialog

und der neuen „vertikalen“ Variante

„Vertikaler“ Eingabedialog

wählen. Selbstverständlich unterstützen beide Varianten beliebig viele Bobbl, nicht nur zwei wie in dem gezeigten Beispiel. Das gewählte Layout spiegelt sich auch in der Tabelle der bisher eingegebenen Spielstände und in der Formatierung der Turnier-Export-Daten wieder.

Kontinuierlicher Vergleich der Spielstände im Netzwerkbetrieb

Bei größeren Turnieren (oder auch generell) bietet es sich an, alle Ergebnisse unabhängig voneinander an zwei Rechnern einzugeben. Damit können Eingabefehler gefunden werden, denn ein Zahlendreher ist schnell passiert, und immer wieder sind Spielstandzettel auf den ersten Blick nicht klar und eindeutig.

Der augenscheinlich einfachste Weg, Unterschiede zu finden, ist der Vergleich der Rangliste. Ist die Rangliste identisch, müssen auch die eingegebenen Ergebnisse identisch sein. Hierfür gab es in früheren Versionen verschiedene Ansätze, vgl. hierzu das Release Announcement für Version 0.7.5, das für Version 0.7.7 und das für Version 3.0 (ab da ging es zumindest einigermaßen …).

Die aktuelle Version bringt ein anderes, neues Konzept. Weil um was geht es? Wir wollen Eingabefehler finden. Und die findet man am besten direkt während der Eingabe. Wenn ein Netzwerk läuft, dann gleicht jetzt jeder Client kontinuierlich und automatisch seine bisher eingegebenen Ergebnisse mit dem Server ab. Das sieht dann (eingeblendet neben der Tabelle mit den bisherigen Ergebnissen) so aus:

Anzeige zur Synchronität der eingegebenen Client-Ergebnisse mit denen des Servers

Die Anzeige wird mit jeder Eingabe bzw. Änderung, sowohl auf der Client- als auch auf der Serverseite, aktualisert. Sofern die Ergebnisse nicht identisch sind, können die Unterschiede aufgelistet werden. Der entsprechende Dialog sieht beispielsweise so aus:

Anzeige der Unterschiede der Ergebnisse eines Clients zu denen des Servers

Damit sollte man nun endlich ganz einfach und vor allem nebenbei, ohne zusätzlichen Aufwand, Eingabefehler finden und vor allem auch leicht korrigieren können.

Manche Konzepte müssen eben einfach ein bisschen reifen ;-)

Verbesserungen in der Suchfunktion

Phonetische Suche

Als neue Option gibt es jetzt die Möglichkeit, eine sog. „phonetische Suche“ durchzuführen. Dabei wird nicht nach der eingegebenen Buchstabenfolge (oder Abwandlungen davon) gesucht, sondern nach dem Klang der Aussprache des Suchbegriffs. Implementiert ist das mit Hilfe des „Kölner Phonetik“-Algorithmus.

Beispielsweise kann man so den Namen „Raithel“ auch mit dem Suchbegriff „Reidl“ finden. Womöglich ist gerade das jetzt Zufall, aber bemerkenswerterweise findet man auch Uwe Trczelinski, einen er beiden Gewinner des 1. Hofer Aufmuckers 2017, wenn man (entsprechend der Aussprache des Namens) nach „Tschilinski“ sucht.

Die phonetische Suche kommt, sofern sie neben dem Namen-Eingabefeld auf der Anmeldeseite aktiviert ist (das ist sie standardmäßig) beim Import von Paar- bzw. Spielerlisten und auch beim Anmelden neuer Paare bzw. Spieler zum Einsatz und sollte besser vor ungewollten Doppelanmeldungen schützen.
Beispiel: Das Paar „Bauer Martin / Schmidt Bernd“ ist angemeldet, und fälschlicherweise wird versucht, „Bernd Schmitt / Martin Bauer“ anzumelden. Das ging der bisherigen Suchfunktion durch die Lappen, wird aber durch die phonetische Suche jetzt als potenzielles Duplikat gemeldet.

Der Nachteil der phonetischen Suche ist die Tatsache, dass sie – durch die systembedingte und auch gewollte große Unschärfe – potenziell auch viele falsch positive, also unpassende bzw. ungewollte Treffer liefert. Deswegen muss sie aktiv mit einem Klick auf den Ohr-und-Schall-Symbol-Button eingeschaltet werden:

Suchleiste mit Button für die „phonetische Suche“

Einen großen Nutzen sollte diese Funktion vor allem dann haben, wenn man mit vielen Voranmeldungen arbeitet und den bzw. die Namen nicht richtig versteht und/oder falsch schreibt. Denselben Vorteil sollte sie auch dann bringen, wenn z. B. nach dem Turnier die Leute ihre Platzierung wissen wollen und man die Rangliste mit viel Lärm außenherum durchsuchen will.

Tolerantere Standardsuche

Weiterhin wurde die normale Suchfunktion um einen weiteren Aspekt toleranter gemacht: Aufeinanderfolgende gleiche Buchstaben. Diese werden jetzt dahingehend berücksichtigt, dass man Namen wie „Heerdegen“ jetzt z. B. auch bei der Suche nach „Herdeegen“ finden kann.

Überarbeitung der Match-Funktion

Abgesehen davon wurde die Implementierung der Match-Funktion (die die Übereinstimmung des Suchbegriffs mit einer gegebenen Zeichenfolge prüft) überarbeitet. Diese kommt jetzt ohne reguläre Ausdrücke und mit viel weniger zu vergleichenden Varianten aus (maximal drei plus ggf. die phonetische Variante).

Die Änderungen resultieren in einer ganz erheblichen Steigerung der Geschwindigkeit der Suche: Sie benötigt jetzt nur noch ca. 1/65(!) der Zeit der vorhergehenden Versionen, das sind gut 98 % weniger.
Dies macht sich insbesondere beim Import einer langen Paar- bzw. Spielerliste bemerkbar: Hier hat die Suche nach potenziellen Duplikaten bisher selbst auf leistungsfähigen Computern sekundenlang gedauert. Jetzt geht das auch auf älterer Hardware ohne merkliche Verzögerung, innerhalb eines Mausklicks.

Änderungen an der Ranglistenseite

Die „gegnerischen geschossenen Tore“ werden jetzt standardmäßig bei der Erstellung der Rangliste berücksichtigt. Schließlich liegen die Daten ja vor, warum sollte man sie nicht zur Unterscheidung von Platzierungen nutzen? Ob oder ob nicht die gegnerischen Tore per Voreinstellung berücksichtigt werden sollen, kann jetzt auch im „Turnier starten“-Dialog und per Vorlage für neue Turnierdatenbanken festgelegt werden.

Weiterhin gibt es eine neue Anzeigeoption auf der Ranglistenseite: „Nicht entscheidende Tore ausgrauen“. Damit werden Tore bzw. gegnerische Tore, die für die Platzierung nicht relevant sind, grau dargestellt. Die Option kann über das neue „Einstellungen“-Menü ein- und ausgeschaltet werden. Das ist unter dem gleichnamigen Knopf zu finden, der sich jetzt an der Stelle der Checkbox „Gegnerische Tore berücksichtigen“ befindet. Diese Option ist ebenfalls in das Menü gewandert.

Eine „ausgegraute“ Rangliste sieht beispielsweise so aus:

Beispiel für eine „ausgegraute“ Rangliste

Passend dazu kann man jetzt auch beim Export auswählen, was mit nicht relevanten Toren passieren soll: Sie können jetzt immer angezeigt, eingeklammert oder auch ausgeblendet werden.

Überarbeiteter „Turnier starten“-Dialog

Der „Turnier starten“-Dialog bringt jetzt deutlich mehr Einstellmöglichkeiten. Alle sind auch Bestandteil der Vorlage für neue Turnierdatenbanken. Diese Vorlage kann jetzt außerdem direkt im Dialog gesetzt bzw. aktualisert werden.

Neben den Grundeinstellungen „Turniertyp“, „Punkte pro Bobbl“ und „Bobbl pro Runde“ stehen jetzt, wenn die Option „Erweiterte Einstellungen“ aktiviert ist, folgende Optionen zur Vorauswahl:

Turnier abschließen

Ein weiteres neues Feature ist die Möglichkeit, ein Turnier abzuschließen. Wenn Ergebnisse vorliegen und alle Runden abgeschlossen sind (das Turnier also potenziell beendet ist), kann man via „Datei“ → „Turnierstatus festlegen“ das Turnier als „abgeschlossen“ deklarieren. Das bewirkt – unabhängig von einem dateisystemseitigen Schreibschutz – dass das Turnier nicht mehr (aus Versehen) verändert werden kann.

Sind trotzdem Änderungen nötig, dann kann der Status (natürlich nur dann, wenn die Datei an sich nicht schreibgeschützt ist) jederzeit wieder auf „offen“ gesetzt werden.

Auswahl weiterer Neuerungen und Bugfixes

Relevante „interne“ Änderungen

… die die meisten wohl eher nicht interessieren, aber nicht unerwähnt bleiben sollen.

Die Lizenz des Projektes wurde von „GPLv2“ auf „GPLv3 or later“ geändert.

Für alle, die selber kompilieren, ist folgendes wichtig: Es wird jetzt mindestens Qt 5.11 benötigt (statt bisher Qt 5.7) und ab jetzt nutzt der Quellcode den C++17-Standard (statt bisher C++11). Nutzer von Binärpaketen bzw. Installern braucht das natürlich nicht zu kümmern.

Eine weitere, aber auch vermutlich nur für Wenige relevante Änderung ist: Der Prüfsummen-Algorithmus (u. A. für die Prüfsumme der Rangliste) wurde überarbeitet. Die bisherige Implementierung könnte (zumindest theoretisch) trotz unterschiedlicher zugrundeliegender Ranglisten in derselben Prüfsumme resultieren. Das sollte jetzt nicht mehr passieren, allerdings werden jetzt für dieselben Datenbestände ganz andere Prüfsummen ausgegeben, als bisher.

Alle Änderungen enthält wie immer der ChangeLog. Viel Spaß mit der neuen Version :-)

10 Jahre Muckturnier-Programm

… und kein Muckturnier auf dem Hofer Volksfest. Heute wär’s gewesen. Ein Jammer. Hoffen wir, dass die Suche nach einem Corona-Impfstoff erfolgreich ist, und dass wir das nächstes Jahr nachholen können! Daumen drücken, vielleicht wird ja 2021 wieder alles normal. Oder zumindest besser.

Anlässlich des heutigen Tages habe ich nochmals die Akten gesichtet und festgestellt, dass die bisherige Aussage „Den ersten Code für das Programm gabe ich 2011 geschrieben“ nicht stimmen kann.

Der (mittlerweile korrigierte) Eintrag Nostalgische Gefühle: der PHP-Code von Muckturnier jetzt in Git hatte und hat sicher Recht damit, dass der erste Code für das Muckturnier-Programm am 04.03.2011 in meinem damaligen Subversion-Repository gelandet ist. Deswegen habe ich dieses Datum (was zeitlich ja auch passend kurz nach dem 9. Muckturnier der JU Leupoldsgrün gewesen sein düfte) auch als Projekt-Start angenommen. Nur habe ich nicht schon immer ein Content Versioning System benutzt (ganz früher™ wusste ich nicht, was das ist, und wie man das macht mit der Softwareentwicklung ;-)

Nun gibt es ja aber auch noch das Release Announcement für Version 0.1, die erste veröffentlichte Version. Und darin steht: „Nach dem zweimaligen öffentlichen Betatest auf dem alljährlichen Muckturnier der JU Leupoldsgrün […] ist es jetzt Zeit für das erste stabile Release“.

Den Beitrag habe ich am 04.03.2012 geschrieben, höchstwahrscheinlich kurz nach dem 10. Muckturnier der JU Leupoldsgrün. Folgerichtig war das also der „2. öffentliche Betatest“. Der 1. war dann 2011, auf dem 9. Muckturnier der JU Leupoldsgrün. Da gab es ja aber den Code schon. Also habe ich – aller Wahrscheinlichkeit nach – bereits auf dem 8. Muckturnier der JU Leupoldsgrün Ende Februar/Anfang März 2010 den Entschluss gefasst, das Projekt zu starten. Und ein Jahr später wurde das erste Muckturnier mit dem Programm ausgewertet.

Wir feiern also dieses Jahr das 10jährige – leider allein und in aller Stille. Aber mit viel Entwicklungszeit für viele Innovationen und in der guten Hoffnung, dass es 2021 wieder weitergeht :-)

Quellcode jetzt auf GitLab

Einen eigenen Git-Server zu haben ist ganz nett, aber zugegebenermaßen doch eher Spielerei (der Beweis für „ich kann das auch selber“ ;-). Aber die Großen können es dann doch etwas besser, mit schicken Diff-Views, Bugtracker und so weiter.

Jeder kennt ja den Git-Hosting-Platzhirsch GitHub. Nachdem das KDE-Projekt seine Git-Infrastruktur kürzlich auf die Software von GitLab umgestellt hat, habe ich dieser Lösung aber doch den Vorzug gegeben (ich bin ja nebenher auch KDE-Developer, und GitLab ist toll).

Ab jetzt wird der Quellcode des Muckturnier-Projektes nicht mehr auf meinem eigenen kleinen Server gehostet, sondern auf GitLab unter https://gitlab.com/l3u/muckturnier. Mit allen Vorzügen, die ein großer Git-Hoster hat.

Für den vermutlich eher unwahrscheinlichen Fall, dass jemand das Repsitory ausgecheckt hat: Bitte die Remotes von git://git.l3u.de/muckturnier.git auf https://gitlab.com/l3u/muckturnier.git umstellen.

Technology Preview: Auslosung bei der Anmeldung

Klassischerweise wird bei einem Muckturnier erst fertig angemeldet, und wenn alle Teilnehmer in der passenden Anzahl da sind, dann wird ausgelost. Meistens, indem ein Spieler jedes Paars (bzw. jeder Spieler bei Einzelspielerturnieren) einen Zettel mit einer Tisch- und Paarnummer zieht.

Für das Hofer Volksfest hätte dieses Vorgehen viel zu lang gedauert; weiterhin wussten wir nicht, wie viele Tische letztlich wirklich besetzt sein würden. Deswegen haben wir das bisher so gehandhabt, dass es einfach eine sequenzielle Vergabe direkt bei der Anmeldung gab (das erste Paar ist „Tisch 1 Paar 1“, das zweite „Tisch 1 Paar 2“, das dritte „Tisch 2 Paar 1“ und so weiter).

Dieses Vorgehen wurde – zurecht – wegen der fehlenden Zufälligkeit kritisiert, und auch dafür, dass es ein gewisses Taktieren (hinter wem stelle ich mich an) zuließ. Allerdings blieb uns bisher nichts anderes übrig, da eine „richtige“ Auslosung wie gesagt viel zu zeitaufwändig gewesen wäre, und die Auslosung ja auch lückenlos und fortlaufend sein muss, damit es losgehen kann.

Aber dafür gibt es jetzt eine Abhilfe!

Vergabe der Auslosung direkt beim Anmelden

Die nächste Version vom Muckturnier-Programm (3.4, Release t. b. a.) wird ein gangbares Konzept für die Auslosung direkt bei der Anmeldung mitbringen. Mit Version 3.3 hatte man schon die Möglichkeit, eine Auslosung vor dem Turnierstart einzugeben. Der Auslosungsdialog stellte einfach immer den nächsten freien Platz ein, entsprechend der sequenziellen Platzvergabe.

Ab Version 3.4 kann man diese Platzvergabe bei der Anmeldung so zufällig machen, wie man will. Die sequenzielle Vergabe steht weiterhin zur Verfügung, entweder als alleinige Option oder als Bestandteil einer zufälligen Platzvergabe. In diesem Fall mit einem Parameter, ab welchem Tisch die Plätze sequenziell vergeben werden sollen, oder ob überhaupt. Weiterhin kann man bis zu einem bestimmten Tisch komplett zufällig auslosen. Aber der Clou ist das dazwischen: Die Vergabe der Plätze in einem bestimmten „Fenster“ von Tischen, nämlich eine bestimmte Anzahl von Tischen nach dem Tisch mit dem ersten freien Platz.

Der zugehörige Einstellungen-Dialog (aufzurufen über den „Einstellungen“-Knopf auf der Anmeldeseite oder direkt beim Erstellen des Turniers) sieht so aus:

Dialog „Einstellungen für die Auslosung“

Wenn man mit einem „Vergabefenster“ auslost, dann ist die Vergabe der Plätze hinreichend zufällig, aber doch sequenziell: Es werden zunächst alle Plätze in dem Fenster zufällig ausgelost. Wenn der erste Tisch des Fensters voll besetzt ist, dann rückt das Fenster weiter. Somit ist die Auslosung bis zum Beginn des Fensters auf jeden Fall vollständig und lückenlos.

Bereinigung der Auslosung

Durch die Zufälligkeit kann es natürlich vorkommen, dass am Ende der Anmeldung am hinteren Ende Tische gar nicht oder nur teilweise besetzt sind, es also Lücken gibt. Das heißt, dass man Paare bzw. Spieler umsetzen muss, damit es losgehen kann.

Aber auch dafür gibt es eine Lösung: Die „Bereinigung“ der Auslosung. Der entsprechende Dialog kann aufgerufen werden, sobald die passende Anzahl an Paaren bzw. Spielern angemeldet sind und es keine als allein oder abwesend markierten Anmeldungen mehr gibt.

Der Algorithmus rechnet die optimale Variante für das „Bereinigen“ aus, bei der sich möglichst wenige Paare/Spieler umsetzen müssen. Weiterhin wird darauf geachtet, möglichst viele in der bereits zugelosten Rolle „Paar 1“ bzw. „Paar 2“ zu lassen. Das sieht dann z. B. so aus:

Auslosung bereinigen

Ein, zwei Paare am Ende der Anmeldung umzusetzen geht viel schneller als eine klassische Auslosung. Als Bonus weiß das Programm weiterhin bereits in der 1. Runde, wer wo sitzt, und es ist schon zu Beginn die automatische Paarauswahl über die Tischnummer möglich. Das vereinfacht und beschleunigt die Auswertung ungemein. Außerdem ist es natürlich sicher auch kein Nachteil, wenn die allermeisten gleich nach der Anmeldung wissen, wo sie sitzen, sich schonmal häuslich einrichten und ein Bier bestellen können ;-)

Nähere Betrachtung der „Fenster-Auslosung“

Für En­thu­si­asten und/oder Mathematiker und/oder Statistiker.

Statistische Auswertung

Für ein so systemkritisches Programm wie das Muckturnier-Programm sollte man natürlich nicht „einfach so“ ein Feature zum EDV-gestützten Auslosen anpreisen, ohne dass man als Veranstalter weiß, auf was man sich einlässt ;-) Deswegen war ich so frei, diese Auslosungsvariante ein bisschen statistisch aufzuarbeiten.

Hierzu habe ich einen Test-Datensatz mit 20 Paaren bzw. 40 Spielern (also 10 Tischen) erzeugt, und alle Plätze mit 1 bis 5 Tischen nach dem ersten Tisch mit einem freien Platz zufällig vergeben. Dann wurde überprüft, wie viele Paare bzw. Spieler man vor dem Beginn des Turniers hätte umsetzen müssen. Für jede Variante wurden 100 Messungen erhoben. Das Ergebnis sieht in einem Box-Whisker-Plot folgendermaßen aus (das arithmetische Mittel ist jeweils zusätzlich durch ein Kreuz markiert):

Notwendige Umsetz-Aktionen in Abhängigkeit der Größe des Vergabefensters

Wenn man sich die Stichproben genauer ansieht, dann findet man Folgendes (ein Signifikanzniveau von α = 0,05 zugrundegelegt):

Keine der Messungen lag normalverteilt vor (Kolmogorow-Smirnow-Test, p ≪ 0,05), somit waren zur weiteren Untersuchung nicht-parametrische Tests angezeigt.

Bei den festen Paaren resultierten weniger große Fenster in jeweils signifikant weniger nötigen Operationen vor dem Turnierbeginn (Wilcoxon-Vorzeichen-Rang-Test, p < 0,05). Bei den einzelnen Spielern zeigten lediglich die Gruppen „+3“ und „+4“ keine signifikanten Unterschiede (p > 0,05); inwiefern das sich bei mehr Stichproben auch noch ändern würde, wäre weiter abzuklären.

Fazit und Empfehlung

Die „Fenster-Auslosung“ ist ein gangbares Mittel, um eine Auslosung direkt bei der Anmeldung zu realisieren, ohne zu wissen, wie viele Tische letztlich besetzt sein werden.

Die Anzahl der Lücken, die bei dieser Variante der Auslosung entstehen, steigen erwartungsgemäß mit der Größe des Fensters, und somit auch die Anzahl der Operationen, die vor dem Turnierbeginn nötig sind, um die Auslosung zu bereinigen.

Die Auswahl „+4“, also ein Vergabefenster von 5 Tischen, scheint sowohl für feste Paare als auch für einzelne Spieler ein vernünftiger Kompromiss zwischen Zufälligkeit und Beherrschbarkeit zu sein. Hier wird ein relativ großer Bereich zufällig verlost, aber trotzdem müssen vor dem Turnierbeginn im Median nur zwei Paare bzw. Spieler umgesetzt werden; im arithmetischen Mittel sind es bei Paaren etwas weniger, bei Einzelspielern etwas mehr.