Das Schweizer System verständlich erklärt

Wenn viele Spieler nur wenige Termine haben, kann nicht jeder gegen jeden spielen. Das Schweizer System lost deshalb in jeder Runde Spieler mit ähnlichem Punktestand gegeneinander aus. Diese Seite erklärt zuerst ohne Formeln, wie diese Auslosung funktioniert und warum ihre Regeln schwer in ein Programm zu fassen sind. Danach zeigt sie für Fachleute, wie die Demo ihre Auslosung gegen das offizielle Referenzprogramm geprüft hat, welche Fehler dabei auftauchten und wo die Aussage endet.

Zuletzt aktualisiert: 3. November 2026

Ein Wort unbekannt? Das Begriffsverzeichnis erklärt es in wenigen Sätzen.

Wer spielt gegen wen?

Eine offene Schachmeisterschaft hat viele Teilnehmer, aber nur wenige Spieltage. Wenn jeder gegen jeden spielen sollte, bräuchte man fast so viele Runden, wie es Spieler gibt. Ein Turnier mit Ausscheiden wirft dagegen schon nach einer Niederlage hinaus. Beides will man nicht.

Das Schweizer System macht es anders: Alle spielen in jeder Runde, und in jeder Runde wird neu ausgelost. Wer viele Punkte hat, spielt gegen andere mit vielen Punkten, wer wenige hat, gegen andere mit wenigen. Nach einigen Runden stehen die Besten oben, obwohl sie längst nicht gegen alle gespielt haben.

Wie eine Runde ausgelost wird

Die Auslosung folgt einer festen Reihenfolge von Schritten:

• Gruppen bilden. Alle mit gleichem Punktestand kommen in eine Gruppe, die Gruppen werden von oben nach unten abgearbeitet.
• Innerhalb der Gruppe. Die obere Hälfte der Gruppe spielt gegen die untere Hälfte, geordnet nach der Setzliste: der Beste gegen den Ersten der unteren Hälfte, der Zweite gegen den Zweiten, und so weiter.
• Nie zweimal dieselbe Partie. Wer schon gegeneinander gespielt hat, darf nicht wieder gelost werden.
• Farben abwechseln. Jeder soll möglichst abwechselnd Weiß und Schwarz spielen, niemand zu oft mit derselben Farbe.
• Ungerade Zahl. Dann bekommt ein Spieler spielfrei und dafür einen Punkt, nie zweimal derselbe.
• Wenn eine Gruppe nicht aufgeht. Bleibt jemand übrig, rutscht er in die nächste Gruppe darunter und spielt dort gegen jemanden mit weniger Punkten. Solche Spieler heißen „Absteiger“.

Warum das schwer zu programmieren ist

Die Regeln sind keine Rechenvorschrift, sondern eine Rangliste von Wünschen. Einige gelten immer, etwa dass niemand zweimal denselben Gegner bekommt. Andere sind Wünsche, die man nur so weit erfüllt, wie die höher stehenden es erlauben: möglichst wenige Absteiger, möglichst schwache Absteiger, dann gute Farbverteilung, dann dass niemand zweimal hintereinander absteigen muss. Gerät ein Wunsch mit einem höher stehenden in Konflikt, gewinnt der höhere.

Ein Programm muss diese Reihenfolge nicht nur kennen, sondern auch in einem kniffligen Fall dieselbe Antwort geben wie alle anderen. Deshalb gibt es ein offizielles Referenzprogramm, mit dem man andere Programme vergleicht.

Die Beschleunigung

In den ersten Runden stehen die Ergebnisse oft schon fest, weil starke Spieler gegen schwache gewinnen. Die Baku-Beschleunigung ändert das. Die obere Hälfte der Setzliste bekommt in den ersten Runden gedachte Zusatzpunkte, nur für die Auslosung. So treffen die Favoriten früher aufeinander, und es steht schneller fest, wer wirklich vorn ist. Die Tabelle zeigt weiter nur die echten Punkte.

Was die Demo zeigt

Die Demo lost simulierte Turniere aus und kann das auf zwei Wegen tun: Der eine folgt dem Regeltext Schritt für Schritt und ist deshalb gut nachzuvollziehen. Der andere baut nach, wie das Referenzprogramm selbst rechnet, und lässt sich nicht in einzelne Regelschritte zerlegen. Beide werden mit dem Referenzprogramm verglichen, Runde für Runde auf vielen zufälligen Turnieren.

Dabei fielen Fehler auf, die ein Test, der nur die Paarungen vergleicht, nicht gefunden hätte, zum Beispiel bei der Verteilung der Farben. Erst der genaue Vergleich Paar für Paar und mit Farbe machte sie sichtbar. Wie gut die beiden Wege am Ende übereinstimmen, steht im Fachteil.

Wie ernst ist das Modell zu nehmen?

Alle Turniere sind simuliert: Die Spielstärken sind erfunden, die Ergebnisse werden ausgewürfelt. Die Demo zeigt, dass die Auslosung den Regeln und dem Referenzprogramm folgt, nicht, wie sich echte Turniere entwickeln. Ob eine Auslosung gut ist, hängt auch vom Veranstalter ab, etwa davon, ob er die Beschleunigung will.

Hinweis: Alle Demos rechnen mit synthetischen oder frei verfügbaren Beispieldaten und laufen auf einem externen Anbieter (Datenschutz). Bitte geben Sie darin keine vertraulichen oder personenbezogenen Daten ein. Die Ergebnisse gelten für die jeweilige Demo-Instanz und lassen sich nicht ungeprüft auf reale Fälle übertragen; für darauf gestützte Entscheidungen übernehme ich keine Gewähr.

Modell und Annahmen

Die Demo setzt das Dutch-System der FIDE (C.04.3, Fassung ab 1. Februar 2026) um: Brackets nach Punktestand von oben nach unten (Art. 1.9.2), Paarung je Bracket nach Art. 3 und 4 (obere Hälfte S1 gegen untere Hälfte S2, dann Transpositionen und Tausche in fester Reihenfolge), Farbzuteilung nach Art. 5.2. Die Kriterien C1 bis C3 sind absolut (keine Wiederholung, kein zweites Freilos, keine Kollision gleicher absoluter Farbpräferenz außer bei Spitzenreitern), C4 verlangt eine vollständige Runde, C5 minimiert den Score des Freilos-Empfängers, C6 bis C9 betreffen Zahl und Scores der Absteiger, C10 bis C13 die Farben, C14 bis C21 wiederholte Floats.

Die Baku-Beschleunigung folgt FIDE C.04.7: Gepaart wird nach dem Paarungs-Score, der Summe aus echtem Punktestand und gedachten Zusatzpunkten der Gruppe GA. Es gibt zwei Engines: den Regeltext-Modus (Art. 3 und 4 wörtlich, Schritt für Schritt erklärbar) und einen bbpPairings-treuen Modus (ein einziges rundenweit fortgeführtes gewichtetes Matching, aus dem Quellcode des Referenzprogramms portiert). Referenz ist bbpPairings in Version 6.0.0, das offizielle, von der FIDE anerkannte Programm. Gespielt wird im Modell nach dem Elo-Erwartungswert.

Die Formeln

Der Ausgang einer simulierten Partie folgt dem Elo-Erwartungswert: Spieler A mit Wertung \(R_A\) gegen B mit \(R_B\) erreicht im Mittel den Punktanteil

\[E_A = 1/(1+10^{(R_B-R_A)/400})\]

Bei der Baku-Beschleunigung bilden die ersten Spieler der Setzliste die Gruppe GA, die obere Hälfte aufgerundet auf eine gerade Zahl (Art. 1.2). Bei \(N\) Spielern hat sie die Größe

\[|G_A| = 2\left\lceil N/4 \right\rceil\]

Beschleunigt werden die ersten \(a = \lceil R/2 \rceil\) von \(R\) Runden. Vor der ersten Hälfte davon bekommt GA einen gedachten Punkt, vor den übrigen beschleunigten Runden einen halben, danach nichts mehr; gepaart wird nach \(s_i + v_r\) für \(i \in G_A\):

\[v_r = 1 \ (r \le \lceil a/2 \rceil), \quad v_r = 1/2 \ (\lceil a/2 \rceil < r \le a), \quad v_r = 0 \ (r > a), \qquad a = \lceil R/2 \rceil\]

Wie die Demo eine Runde löst

Im Regeltext-Modus trennt die Demo zwei Phasen. Die Kriterien C5 bis C9 hängen nur davon ab, wer aus jedem Bracket herausfällt, nicht davon, wie der Rest gepaart wird. Phase 1 bestimmt deshalb die Kette der Absteiger-Mengen per dynamischer Programmierung über (Bracket, hereinfallende Spieler), mit einem billigen Matching-Test statt einer Kandidatenliste: C6 und C7 je Bracket von oben nach unten, C8 nur für den folgenden Bracket, das Freilos über eine Obergrenze für seinen Schlüssel. Phase 2 liest entlang dieser Kette je Bracket die Kandidaten nach C10 bis C21 sortiert, bei Gleichstand entscheidet die Erzeugungsreihenfolge des Regeltexts.

Befunde

Alle Zahlen sind Übereinstimmungen der Demo mit bbpPairings auf simulierten Turnieren, in denen bbpPairings das Turnier selbst fortführt, damit beide Seiten denselben Stand sehen. Gezählt wird, ob Paarung, Freilos und Farben einer Runde übereinstimmen.

Frage	Befund
Stimmen die Auslosungen auf kleinen Feldern?	Ja, in beiden Engines: 1430 von 1430 Vergleichen (4 bis 16 Spieler, 1 bis 4 Runden) und 1994 von 1994 auf einer bewusst härteren Stichprobe (6 bis 19 Spieler, bis 6 Runden).
Und auf größeren Feldern?	574 von 574 Runden (8 bis 31 Spieler, 5 bis 9 Runden), mit Baku-Beschleunigung 576 von 576, jeweils in beiden Engines.
Stimmt die Farbzuteilung?	0 Abweichungen auf 5068 Paaren der Referenz. Davor waren es 76: Art. 5.2.3 war als „jeder wechselt zu seiner letzten Farbe“ umgesetzt statt als Vergleich der Historien, wie ihn bbpPairings über die gespielten Partien rechnet.
Wie schnell ist der Regeltext-Modus?	Median 1,2 s je Turnier, schlechtester Fall 2,7 s (31 bis 32 Spieler, 9 Runden, CPU-Zeit). Vor den Änderungen waren es 1,8 bis 1,9 s und 5,0 s bei 94,4 % Übereinstimmung.
Wie kam die Übereinstimmung des Regeltext-Modus von 94,4 % auf 100,0 %?	In mehreren Schritten, jeder behob einen Umsetzungsfehler (siehe unten). Den größten Sprung brachte die Bewertung ungepaarter Absteiger bei C18 und C20 (98,6 auf 99,5 %).
Kostet die Baku-Beschleunigung Genauigkeit?	Nein: Paarungen, Freilos und Farben stimmen mit ihr ebenso überein wie ohne.

Was der Abgleich aufdeckte

Fast alle Abweichungen waren Umsetzungsfehler und keine Tie-Break-Fragen. Jede wurde an einem kleinsten Fall bis zur Ursache verfolgt und bekam einen Regressionstest gegen bbpPairings:

• Spitzenreiter-Grenze (Art. 1.8). Die Demo rechnete die Grenze als Hälfte der Gesamtrunden und ließ die Ausnahme von C3 in jeder Runde zu. Richtig, und so rechnet bbpPairings, ist die Hälfte der bereits gespielten Runden, nur in der letzten Runde.
• Farbregel 5.2.3 mit Freilosen. bbpPairings zählt in jeder Historie die k-te jüngste gespielte Partie, Freilose übersprungen, nicht dieselbe Rundennummer.
• C18 bis C21. Bewertet werden die Score-Differenzen der MDP-Paare (Absteiger im neuen Bracket), nicht die Scores einzelner Spieler; ein zuvor gefloateter MDP, der ungepaart bleibt, ist schlechter als jede Paarung.
• Tauschreihenfolge (Art. 4.3.2). Verglichen werden Bracket-Folgenummern, nicht Startrangnummern.
• C8 nur für den folgenden Bracket. Ein Vergleich über die ganze Restkette ließ ein besseres C7 weit unten die Farbe im aktuellen Bracket überstimmen.
• Kandidatenstrom gedeckelt. Die perfekte Paarung fehlte in einem Bracket mit zwei Absteigern; eine gezielte Suche je gewählter Menge behebt das.

Nur ein Vergleich Paar für Paar und mit Farbe findet solche Fehler; ein Test, der nur die Paarungen vergleicht, übersah sie, solange die Paarung zufällig stimmte.

Grenzen

• 100 % heißt 100 % auf diesen Stichproben, nicht bewiesen gleich. Andere Feldgrößen, Rundenzahlen oder Ergebnisverteilungen können weitere Abweichungen zeigen.
• Das Referenzprogramm ist ein Maßstab, kein Beweis der Korrektheit: Die Demo zeigt, dass sie ihm folgt, nicht, dass seine Auslosung die einzig mögliche ist.
• Alle Turniere sind simuliert (erfundene Wertungen, ausgewürfelte Ergebnisse), keine echten Daten.
• Nachmeldungen (Art. 1.3) sind nicht abgebildet, das Feld ist fest. Als Beschleunigung gibt es nur das Baku-Verfahren, das einzige in C.04.7 beschriebene.
• Der bbpPairings-treue Modus lässt sich nicht in Einzelschritte zerlegen, der Regeltext-Modus schon: beide stimmen auf diesen Stichproben überein, erklären aber Unterschiedliches.
• Mutationstest und Textprüfung sind für diese Reihe von Änderungen nicht gelaufen.

Quellen

• FIDE Handbook, C.04.3 FIDE (Dutch) System, effective from 1 February 2026 (handbook.fide.com/chapter/C0403202602).
• FIDE Handbook, C.04.7 FIDE-approved Accelerated Systems, Baku Acceleration Method (handbook.fide.com/chapter/C0407202602).
• bbpPairings, Version 6.0.0, github.com/BieremaBoyzProgramming/bbpPairings (Referenzprogramm, Quellcode und Testfälle).

Die FIDE-Texte wurden im Webportal des Handbuchs gelesen; der Quellcode von bbpPairings 6.0.0 wurde für die Umsetzung gelesen.