In the third round of a four-round Swiss, Player A, rated 1700, had already played round one with white and round two with black. He was being paired with Player B, rated 1750, who did not play in either of the first 2 rounds.
My understanding of color assignments was that Player A was due for white for alternation of colors. Player B, not having played yet, was not due for either color. So Player A should get white as his due color, and B should get black.
However, WinTD assigned Player B white. I’m guessing this is because both players had equal color “history” so it gave white to the higher rated player. But I’m not sure that’s right under the current rules.
The WinTD setting did not include using full-color history. It should still have alternated colors anyway.
The player was scheduled for white in round two and played black while the computer thought that he had two whites in a row. This would be my first guess.
There were no forfeits by Player A and no errors in colors assigned vs. played in earlier rounds.
In the preferences setttings for pairing rules, “Due Color to Higher Ranked” was checked, but according to WinTD’s help files, this should not have affected the assignment unless both players had just played a round with the same color, which of course they didn’t. As a test however, I backed the system up to repair round 3 and removed the check mark, and the pairings still gave Player B white.
I’m just surprised that such a trusted program would get a basic issue like this wrong. I’ll follow up with WinTD directly and see if they have any good answers.
This just has to be one of those “you’re not telling us something” situations.
Were both of player A’s previous games in the same section, or was one of them in another section, such as an “extra games” section? The program probably wouldn’t look in other sections to find color history.
Maybe if we could see the entire crosstable, including colors, we might see something.
Looking at the crosstable on MSA, all I see is that it was a small section, 10 players, with four of the players entering late and taking byes for the first two rounds.
My experience has been that pairing software, including both WinTD and SwissSys will sometimes have issues when pairing the later rounds of a small section. It almost appears as if the software gets to the bottom of the section and then works its way back up to find acceptable pairings. In doing this, some of the normal logic is “forgotten” and random pairings will occur.
My guess is that Tom Doan will be the only person capable of giving a correct answer to the current question.
Many years ago two of my students who were twin sisters were playing in the same section of a local scholastic. The tournament was paired with PairPlus. One of the sisters won her first round game while the other lost. The sister who lost in the first round was the lowest rated player in the bottom score group for the second round. She would have been the logical bye for that round. Somehow, PairPlus gave the bye to the sister who had actually won in the first round. The only logical explanation that I could deduce was that the software saw that the one sister was to get the bye and when it was calculating the pairings saw the other sister first, and actually assigned her the bye. Both sisters had the same first initial and a rather long last name, so I assume the software was using a shortened version of the name when assigning the bye.
When pairing a small tournament I much prefer doing it by hand, rather than relying on software to generate the correct pairings. It will often times take more time to correct a computer mistake than it would have taken to pair the round by hand.
A couple of weeks ago at a scholastic tournament, in a section with about 40 players, WinTD spewed out pairings with players playing themselves on back-to-back boards. It was an easy manual fix, of course, but it’s hard for me to conjure up any way for the program to do that. I’m sure our computer operator is or has asked about that, but I haven’t heard the explanation yet. It was kind of funny. One of those players came up to me and said, “I’m paired with myself. What happens”? I said, “you’ll probably win” before taking it to the computer operator to resolve.
The week before the program paired two members of the same school together, even though we had checked the box saying not to do that. More than half of the perfect scores were from the same bonecrusher team, but the program should have paired one of them down to avoid the teammate pairing. The explanation was (and I don’t run the computer myself so bear with me if I’m slightly inaccurate) that we needed to set the level of effort the computer uses to make the pairings higher. We had it at 10, which should theoretically be sufficient. Bumping that to 50 took care of the problem.
There’s an outside chance there could be some small-tournament considerations built into the WinTD pairing algorithms, and that these might explain what the program did in this case.
For example, with 8 players, no late entries, no forfeits, no upsets, the results through 3 rounds, if paired “naturally”, might be as follows.
player rd1 tot rd2 tot rd3 tot
1 w5 1 b4 2 w2 3
2 b6 1 w3 2 b1 2
3 w7 1 b2 1 w5 2
4 b8 1 w1 1 b6 2
5 b1 0 w8 1 b3 1
6 w2 0 b7 1 w4 1
7 b3 0 w6 0 b8 1
8 w4 0 b5 0 w7 0
But now look what happens in round 4. IF we continue to alternate all colors, we end up with absurd pairings:
player rd1 tot rd2 tot rd3 tot rd4
1 w5 1 b4 2 w2 3 b7
2 b6 1 w3 2 b1 2 w8
3 w7 1 b2 1 w5 2 b4
4 b8 1 w1 1 b6 2 w3
5 b1 0 w8 1 b3 1 w6
6 w2 0 b7 1 w4 1 b5
7 b3 0 w6 0 b8 1 w1
8 w4 0 b5 0 w7 0 b2
If, however, we had deliberately assigned the wrong colors on two of the boards in round 3 (without even changing the opponents), we would have:
Now we can make exactly the pairings we want in round 4:
player rd1 tot rd2 tot rd3 tot rd4
1 w5 1 b4 2 w2 3 b3
2 b6 1 w3 2 b1 2 w4
3 w7 1 b2 1 !b5 2 w1
4 b8 1 w1 1 !w6 2 b2
5 b1 0 w8 1 !w3 1 b7
6 w2 0 b7 1 !b4 1 w8
7 b3 0 w6 0 b8 1 w5
8 w4 0 b5 0 w7 0 b6
The moral of the story is, in a small tournament, it is better to have some bad colors in odd-numbered rounds.
If WinTD recognizes this moral, it is just possible that it assigned the wrong color deliberately, in the example which began this thread.
I have no idea how that might have happened. We need would need you (or the backroom guy) to send us the .PTO file (to support@estima.com).
It is possible to put a player in twice (it will warn about possible duplicates, but will let you go ahead), but it would be hard to imagine a situation where a players’ duplicated entries would get paired.
He did say he would be sending you the file. It wasn’t a duplicate entry. This was in the third round! And if there were duplicate records, they still wouldn’t have been paired because both records showed the same school for both of them.
It that had happened, we would have seen a ton of multiple pairings. We saw only two. And since the players were paired against themselves, that would also argue against the duplicate entry or merge theories. After all, even acknowledging that the hypothetical duplicate entries were not recognizable as duplicates to the computer, in a section with plenty of one pointers in the pool, the system would hardly have paired two individuals with identical school codes against each other. Nor would it have been likely to pair people with identical color patterns, not once, but twice consecutively and have the randomness pick these two pairs as the lucky winners of the duplicate pattern sweepstakes.
It seems more likely to me that the hiccup occurred in the “print pairings” routine than in the pairing routine itself. Of course, I’ve never actually used the program, so take my speculation for what it’s worth.
Sorry, I misread your original post. I thought you had said that all players were paired against themselves.
OK. I infer that that pairing was entered by hand, when the late player walked in after the program had already made the other pairings. (Or something like that.)
