WinTD has a checkbox (on the “Pairing Rules” tab of the “Preferences” dialog) labeled “Limit interchanges.” The help file states: “If you check this, WinTD will allow top/bottom interchanges to correct equalization, but not to fix the less serious problem of alternation errors.”
Thanks. Found the checkbox. Now my program agrees with WinTD through round 3. Like WinTD, I made this an option, so it agrees as long as the same option is picked.
Speaking of options, it seems to me like there are a whole lot of options. In some ways that makes sense. I doubt there will be one “best” way of doing pairings. However, the rulebook specifies that if you don’t use the standard Swiss pairings, you have to advertise it in advance. Well, there are an awful lot of options, and no one standard. I’m left to wonder exactly which deviations are so severe that someone could legitimately claim a rules violation if you used those deviations to pair the tournament, and didn’t tell people in advance. I suppose, “If it’s mentioned in the rulebook, it’s ok.” But of course, the rulebook is full of all sorts of variations that were just the pet method of someone at one time. To me, if a tournament is advertised as Swiss style, that means players will be paired in scoregroups. I suppose that some attempt at top half/bottom half pairings should be done, because people associate that with the Swiss pairings. Beyond that, it seems to me that none of the other elements are really essential. As long as it does those two things, it seems Swiss to me, and no specific disclaimer ought to be necessary.
It would be nice if there were an “official algorithm”, including allowed variations. As it is, the rulebook is filled with suggestions and guidelines that are hard to keep straight. Not that it’s exactly vital, but it would be nice.
Another thought. My current focus is on getting the “standard” method right, and then perfecting the simulation mode, so I can actually quantify the behavior of various pairing methods and the results of using them. Has anything like this ever been done before? I suspect that all of these variations listed in the book are basically rules of thumb and ideas used by various people who tend to like something because it solved some problem they encountered once. Has there been anything like a thorough analysis that actually compared results between different pairing methods?
Meanwhile, my round 4 doesn’t agree with WinTD. It seems we have a dispute over who should be the odd man in the two point scoregroup. Back to the debugger.
Agreed. For example, whom to pair up or down when the number of players is odd. Harkness is sufficiently famous and respected that his method, middle-plays-top, is an official variation, even though bottom-plays-top is now the “official” standard. If either middle or bottom may be dropped, why not anyone between middle and bottom? And, for symmetry, why not raise anyone between top and middle in the lower score group?
I doubt, though, that it will ever be possible to completely define a “best” set of pairings. One could strive to minimize the sum of all the differences between each player’s “raw” opponent and his eventual opponent, but there are so many possibilities that a human TD could no longer figure out “best” pairings.
Over the years I have seen several cases where a human TD overruled the pairings made by WinTD, but invariably ended up with pairings that, upon closer examination, were not as good as WinTD. Sometimes the “best” pairings are difficult to find, and when WinTD finds them, they look strange because the human observer is looking only at one or two of the resulting pairings, rather than at the group as a whole.
Bill Smythe
Did either your program or WinTD pair down a player other than the lowest, in order to improve colors? If so, did the colors in the next lower score group get better or worse as a result?
Or, for that matter, are you still using a method you suggested earlier, which would tend to pair the middle player in one group against the middle player in the next group in order to maximize rating differences?
The details would be interesting here.
Bill Smythe
I did an override of the WinTD pairings for the final round of the IL Open top boards. After I did that and before printing, the back room TD changed the setting to allow interchanges, re-paired, and saw WinTD get the exact same pairings I did.
At one NYA WinTD made strange pairings to avoid a teammate match-up, so an override was done (with the Chief TD’s approval) to get more reasonable pairings (the override actually involved a setting change and then a WinTD regeneration - which ended up matching what looked to be the better pairings).
This shows three things.
- It is important to know what settings are selected.
- With the correct settings WinTD can pair at least as well as an NTD.
- Knowing how pairings should look in general can trigger a TD seeing strange pairings to review the settings that worked just fine up to that point. i.e., just because WinTD (or SwissSys) does a magnificent job doing pairings doesn’t mean that you can just blindly accept whatever it did.
P.S. There have been times when I’ve overridden the WinTD pairings and then changed them back once I realized why WinTD paired it the way it did, and after a couple of those I first review and change settings instead of blindly doing an override.
How do you figure? I disagree strongly with your conclusion above. Most strong players are able to figure out pairings, more or less, in the top few scoregroups. Some of the deviations are minor and don’t need to be announced in advance, but some are major and do need to be announced in advance. If you’re going to use Lame pairings, you really ought to announce that. If one of your players appeals, you won’t have a legal leg to stand on. I suppose that you could use “NCAA Basketball” pairings, pairing 1 vs. n, 2 vs. n-1, etc. This would definitely be a major variation and should be announced in advance. Also you could give all higher rated players Black no matter what, and this would be a major variation. Both of these would fit even your most liberal definition of swiss tournaments, but I think you’d agree that some players, at least, would not want to play under those conditions and would be upset if they came all the way to the site without knowing this in advance.
Conversely, if you decided that a father and son wouldn’t play each other no matter what, then I would consider that a minor variation, and you wouldn’t need to announce that in advance, though it’s a good idea to announce that at the site, at least to the players directly effected.
By all means, go ahead and organize tournaments using Lame pairings, just don’t call them swiss system. Who knows, maybe the Lame way will catch on and will replace the swiss system as the way that most tournaments are run in this country.
Alex Relyea
In this particular case, it was just a plain programming bug. My program sent a player down even though he had already played the top player in the next scoregroup. I’m trying to work it out now.
If the bottom player (or whichever player is being downfloated) in group A has already played the top player in group B, it is of course acceptable either to downfloat a different player or to upfloat a different player. Which is better might depend on rating differences (with the smaller transposition getting the nod) or on colors. WinTD probably recognizes this.
Bill Smythe
If memory serves, a single downfloat per tournament (and a single upfloat) would be the normal procedure for FIDE pairings. There are cases where multiple downfloats may be necessary (such as a person being alone in the lead or cellar for multiple rounds).
I’m afraid memory doesn’t quite serve in this case. In the FIDE Swiss pairing rules (Dutch system), under relative criteria:
B.5 has higher priority than B.6, and downfloat and upfloat are considered different floats.
In this case, I simply had a 0 where I should have had an i, resulting in a wrong interchange and some error propogation. I’m now good through round 4.
Round 5 will be tricky, though. The whole process is quite confusing, and I went through the problem of rounds with two odd men or with unpairable players quickly. It didn’t come up until round 5 and, not surprisingly, there were bugs, or at least the final pairings look awfully goofy right now, and not at all what WinTD selected. More debugging awaits.
However, after I get this round, I think I’ll have a working system that will let me at least start trying out the “simulation” mode. I can compare results from USCF/WinTD style pairing with my system. For comparison, I’ll also throw in unrated Swiss, in which I simply ignore ratings altogether, and purely random pairings, in which I ignore everything, and just put two randomly selected players with two randomly selected colors together. Presumably, that last system will have very poor results, which will give a reasonable basis of comparison between the results for other systems.
Does either WinTD or SwisSys have this feature, either automatically or as an option? Somehow I have a hunch that floats in earlier rounds are not kept track of in either program.
With pairing cards, it was easy. Just write an up- or down-arrow next to the opponent number (or the round number) on the pairing card. Then same-direction floats can easily be avoided in future rounds.
Usually, however, the float justifies itself, i.e. the downfloated player loses to the upfloated player. In this case, it hardly seems necessary to avoid floating the same player(s) again.
Bill Smythe
Version 9 of SwissSys (currently in beta test) tracks floats. There is a pairing chart option to display floats; this will show the two previous floats (if any) for each player. I believe Thad intends to submit version 9 to FIDE for validation.
What USCF rule says the player can’t have an identical float in two consecutive rounds? It is late at night and I can’t seem to locate that rule.
jwiewel and wilecoyote (above) claim it’s a FIDE rule. I’ll take their word for it.
I’m pretty sure we’ve never had anything like that as a USCF rule.
At first glance, it has a certain appeal. If you downfloat the same player repeatedly, it looks as though you are giving him easy opponents, round after round, even though he is at the bottom of his score group.
But in practice, the downfloated player is usually lower-rated than his upfloated opponent, because the rating ranges in the two score groups usually overlap.
So the downfloated player is “supposed” to lose. If he does, the float pairing has vindicated itself – he should have lost anyway, being the bottom player in his score group.
But if the downfloated player wins, this could be a sign that he may be vastly under-rated. In this case, it might be wise to avoid downfloating him again, lest he continue to beat up on players in lower score groups. Let him pick on somebody his own size, i.e. in his own score group.
All of the above also applies, in reverse, to the upfloated player (in the next lower score group).
So, in the days of pairing cards, I always liked to keep track of upfloats and downfloats. But I seldom, if ever, found it necessary to actually avoid giving a player a second downfloat, because he usually lost the first one anyway.
Bill Smythe
What is the Lame system? (I assume that’s pronounced lah-MAY.)
Bill Smythe
It must be late at night. Normally you would have caught that it was a FIDE rule being discussed, not a USCF rule.
Yes, on the pronunciation.
The Lame system is what got me started on this exercise. (If you check my USCF ID, you’ll see that I have a real name in addition to Meadmaker.) I wanted to write a pairing program, and I set out some rules for what I thought were good pairings. It didn’t match anything anyone had ever seen, so, earlier in the thread, someone called it “the Lame system”. I rather like the idea, so I kept calling it that. It has also been called “double Harkness”, because it makes the odd man game played against the middle of the top half vs. the middle of the bottom half.
For what it’s worth, I didn’t program it to do “double Harkness”, or even to recognize the existence of odd men in scoregroups or top half/bottom half pairings. I programmed it to favor games with the same record and, less importantly, to favor consistent differences in rank among paired players. The top half/bottom half and “double Harkness” are emergent properties from those rules.
Now, though, I’m trying to implement “standard” Swiss pairings so that I can compare the results of the Lame system to standard pairings. I’m running into some difficulties, but I’m working them out. I’m trying to make my program’s implementation of standard pairings match at least one set of options for WinTD, but I’m running into some pairings that seem rather arbitrary. I’ll post an example after I convince myself it’s not just a programming bug.
Oops, I did indeed neglect to look up your real name. 
No wonder I couldn’t find it on Google (except for tons of lame stuff, pronounced “leighm”), nor on the FIDE website.
Shades of the Benko Gambit! 
Pal Benko played it for two years before he started calling it the Benko, and only then because everybody else by that time was already using that name.
Yeh, that name was my invention – but I think I’ll join others in calling it Lame.
Yes! By starting with goals quite different from those of “standard” Swiss pairings, you have come up with a virtually identical system, except for the way it handles odd players in a score group.
At this point, I think you should not focus on going that last tenth-mile to duplicate existing methods. Rather, you should work on selling your middle-vs-middle method to the other TDs on this forum and elsewhere. Changes like this are not impossible! They just require time, effort, and a lot of arm-twisting.
Already the Lame method is superior, in my opinion, to the Harkness middle-vs-top concept, because of Lame’s symmetry and the way it handles the upfloated player. Often, it would even work better than the now-standard bottom-vs-top method, especially in large single-section events (e.g. U.S. Open) where ratings run the gamut. I’ll go out on a limb and predict that Lame will be as good as, or better than, either bottom-vs-top or Harkness in virtually all circumstances.
When you started this thread, I was skeptical whether you could, in a few months, develop a program whose pairings are as good as WinTD. But now that you’re almost there, I say it’s time to go in a different direction. Use your program to promote a superior idea! Good luck.
Bill Smythe