Pairing oddity

Running Chess Tournaments
1

From the U2100 section of a recent tournament comes the following head-scratcher.

After round 4, the top players, wallchart ratings, and previous color history are as follows.

Player A (2070) 4.0, BWBW
Player B (1961) 4.0, BWWB
Player C (2046), 3.5, BWBW
Player D (2039), 3.5, BWWB
Player E (2038), 3.5, BWBW
Player F (2000), 3.5, BWBW
Player G (1990), 3.5, WBWB
Player H (1926), 3.5, WBBW
Player I (1891), 3.5, -BBW

Notes:

– The only previous pairing involving two of these players was Player E versus Player D in round 4.
– Player I had a half point bye for round 1.
– There were no team codes or other manual restrictions that would have ruled out any normal pairings.

The computer spit out the following round 5 pairings (listed as “white versus black”).

Board 1: Player C versus Player A
Board 2: Player B versus Player E
Board 3: Player D versus Player H
Board 4: Player G versus Player F
(Player I downfloated to the 3-point group.)

I believe SwissSys 8 was the pairing program used. Of course, these pairings are incorrect by inspection.

I managed to get hold of the applicable .s5a file, and played with it at home on my SwissSys 8.82 software. When I flipped one of the decisive 3-pointer results from round 4, and then paired round 5, the pairings were fine. When I flipped the result back to the actual, and then paired round 5, the same issue came up.

What I think happened was that, for some reason, in the above scenario, SwissSys simply stuck the two 4.0 players in the same score group as the 3.5 players. The pairing logic displayed by SwissSys confirms this. On the flipped result I mentioned in the last paragraph, SwissSys pairing logic clearly shows the two 4.0 players in that scenario as being in a separate score group.

My questions: how did SwissSys not pair the co-leaders? And has anyone ever run into this kind of glitch (which is what I’m assuming this is) on SwissSys?

(Yes, Thad Suits will be apprised of the issue. Just curious if anyone’s ever run into it on a reasonably recent incarnation of this software.)

2

Wow, you’ve got me.

When I first saw your results –

– I thought you were going to ask something like:

From the natural
C-F
D-G
E-H
pairings, should one transpose G with F, or G with H, to improve colors?

In that case, I might have been inclined to go with the former, despite the 7-point rating swap (2046-2039) vs a 1-point swap the other way (2039-2038), because then the player getting the “wrong” color would be the one with WBBW, i.e. the one who, among all those due black, is “least” due black.

Oh, well. What could have been a lively debate turned out to be a mere programming glitch. Too bad.

Bill Smythe

3

Actually, I’d drop H to a lower score group instead of I. (The rating difference is 35 points, well within the 80 point limit for improving color alternation.) Then transpose F and G, resulting in:

G - C
D - F
I - E

There, everybody got the due color! :slight_smile:

To make this relevant to the topic, I have not seen SwissSys refuse to pair the only two players in the top score group if they have not met, but I vaguely remember a case of SwissSys breaking up a lower two player score group without justification.

4

Oops, you’re right. I made a beginner’s mistake – I overlooked that player I was due white, even though he had just played white. :blush:

What was going on in the two score groups immediately above and below the two-player group?

Bill Smythe

5

Were the top two players both FMs, with FM in the team code, and things set to avoid team pairings?
Or were they from the same state with the settings to avoid in-state pairings?

In fact, giving a second look at the pairings makes it clear that SwissSys really did recognize that it was floating the two 4-0 players down a score-group since it paired them with the top 3.5-0.5 players. If it was treating them as part of the 3.5-0.5 group then it would have done something like
G-A
B-C
D-F
I-E
H-down
So the question really becomes what setting over-ride was done to get SwissSys to think it had to avoid pairing the top two with each other.

6

I’ve gotten more confident in the programs and thus figure most of the glitches are settings glitches rather than programming glitches (one of the things a good TD can do is recognize weird results and thus figure when the settings need to be corrected, or the pairings need to be corrected if the settings problem cannot be identified). Since it worked fine with a different pair of players at 4-0 it seems extremely likely that it was a setting that was applicable to that particular pair of players.

7

Looking at
main.uschess.org/msa/XtblMain.ph … 3-12479484
I’d guess that the two 4-0 NY players were initially not paired because state avoidance was still set. The 3.5-0.5 players were from CT, MA, NH, NV, NY, TX and VA, so there weren’t any state issues to be noticed.

8

I thought I specified this earlier, but I’ll do it again, to ensure maximum clarity.

There was no manual restriction or setting in the section setup that restricted the natural pairings.

There was no team code assigned to any of the players - and the team code avoidance was turned OFF. So were the club, city, state and ZIP restrictions. The USCF defaults that SwissSys has preset for pairing rules were in full effect, except that random lot numbers for round robins was turned off. That particular setting has nothing to do with this issue.

The section setup was copied from a template used at numerous tournaments. The settings are not at issue here.

9

I looked at the pairing restrictions during the tournament and only saw zip code. Avoiding having 2 NY players facing each other in a NY tournament is just about impossible.

10

I actually briefly clicked ZIP on while looking at the tournament, hoping to find some answer to the problem. That restriction wasn’t even in the original pairing file, and wasn’t in the .s5a file I had copied in my email. Besides, players don’t even have their ZIP codes attached to their entries in these tournaments.

11

Perhaps ‘Look ahead’ pairings? Just grasping at straws here.

12

Are you speculating that look-ahead pairings may have been used, and may have caused the problem, or that they may not have been used, and their absence may have caused the problem?

In any case, I can’t see that as a problem here. Look ahead to what? There were only two players in the score group. Looking ahead to the next score group wouldn’t have changed anything, because reasonable pairings were available in that score group too.

Boyd insists that no flags were set (zip code, etc) that might have caused the problem. I’m wondering if, somehow, some “hidden” flag might have been set. Or, perhaps a flag had been set, then reset, and the “reset” didn’t take.

Bill Smythe

13

So, what has Thad Suits (SyssSys programer/author) got to say about this?

14

Are you calling the question, Tim? :smiling_imp:

15

Nope, a “point of information;” i.e., did anyone contact Suits to get his reaction?

16

The original post stated that he would be contacted. That is in process.