You are ignoring the author of this comment. Click to temporarily show the comment.

In addition to default I'd suggest a capability of customized template. Most club almost always run one or two types of games, they could just load the template and have the information like director name etc. automatically loaded. As of number of table and movement, they could be calculated once pairs are entered. There might be a couple of possible movement options and the program could make suggestion and give options for director to decide.

You are ignoring the author of this comment. Click to temporarily show the comment.

Alan, I think simulation might be a good solution but it might not be very practical. If this pairing program is going to be running on a server, it is not a problem. In practice it is going to be on a TD's laptop and it is probably running multiple events (different flights). So running a Monte Carlo simulation may not be feasible. I think a better way is to get most updated game results from Bridgemate. For most unfinished matches, they should be on the last board. Bridgemate should have all other game results and you could make a very good guess of what match results should be (unless there is big swing on last board). Even you are off by 1 or 2 VP if may not make any differences in pairing results. Of course you could still apply your simulation for these last board results but is would be more manageable.

You are ignoring the author of this comment. Click to temporarily show the comment.

Nick, I see your point. It means there would be not table changes from round to round. Every team is stationary. It would also work when you assign next round before other teams finish because the teams finished already had their table empty. This saves the time players spent to look for their tables every round. It just gives caddies a little more work if it is not using pre-duplicated boards.

You are ignoring the author of this comment. Click to temporarily show the comment.

That's called inflation. What it needs is a real rating system that measures playing ability. There were a couple other threads about this topic recently.

You are ignoring the author of this comment. Click to temporarily show the comment.

Jeff, based on the description in ACBLscore manual about “Matching Tolerance”, the field is not divided in half but a gradual scale determined by the parameters director set up. In the example it gives, the top team has a value of 0% and bottom team has a value of 20% to 80% (default) based number of rounds. This has an effect of given top teams better pairing than bottom teams. The bottom team has a much greater chance to be paired against a higher scored team (up to 16 VP difference) especially when it gets to later rounds.

You are ignoring the author of this comment. Click to temporarily show the comment.

The following is from ACBL Tech file CoC for Swiss team. You could also find information about Swiss pairing algorithm from ACBLscore manual section 3.20.5.5.

PAIRING

1. For the first match of the event, entries will be sold by random

draw (The sponsoring organization may elect to seed the first

match.*). If teams remain without opponents at game time these

teams will be matched as follows: the team with the highest team

number will be reassigned to play the team with the lowest team

number and so on as necessary. When only one such team remains,

that team will play in a three-way match including the two teams

with the nearest team numbers. * This includes, for the first

match, pairing A strat vs A strat, etc. as possible.

2. For each subsequent match, pairings will be assigned (within

groups of teams) such that: a) no two teams shall meet twice in

the event, and, b) 1. each team shall meet a team whose current

record is as close to its own as possible, or 2. for an event with

an even number of entries ONLY (i.e., no three-way matches):

randomly pair teams for their second round match. For the

remainder of the first session or one-half the total number

matches (rounded down)each team shall meet a team whose record

after the previous match is as close to its own as possible.

Current record must be used for the final session or for the last

one-half of the total number of matches (rounded up).

3. If only one team is leading, random draw shall determine which of

its equally eligible opponents it meets. With teams tied for the

lead, pairings shall be such that as many of the tied teams play

each other as possible. This procedure shall be repeated for all

teams still eligible to finish in the overall ranking.

You are ignoring the author of this comment. Click to temporarily show the comment.

Nicolas, since you are making your own Bridgescore+ now and not bound by any requirement from ACBL, why not just build a best Swiss team program using current technology rather than worry about ACBLscore? I think the best solution is to integrate with Bridgemate or at least getting per board result from Bridgemate when you run your Swiss program. In that case you could have best guess for the unfinished team results and use them for next round pairing.

You are ignoring the author of this comment. Click to temporarily show the comment.

Even though A-E pairing is most likely, C could still has a score of 64 and make it not a good pairing. So these teams could not be paired until the score from C-D comes in. As I said in my post early, you could relax rule #2 to gain speed. In this case you'll need to relax it to the point where score difference of 7 VP are treated as equal. Under this condition you could pair A-E. If there is a blitz from C-D, the winner would play B. All these pairing has a maximum difference of 7 vp. If your threshold is 6 VP they could not be paired at this time.

You are ignoring the author of this comment. Click to temporarily show the comment.

The best solution is to assign three way for next round first if there are odd number of teams on odd number of round (three way will go on for two rounds). Then apply standard pairing for the rest of teams.

You are ignoring the author of this comment. Click to temporarily show the comment.

I'm going to give my comments based on my experience as a chess TD. If bridge TD's main task is to manage table movement, chess TD's main job is to do pairing. There are a few rules in Swiss pairing. 1. No teams should be paired twice. This is a hard rule. It could only be broken when the number of rounds equal or greater than number of teams. 2. Teams with same score should be paired together. This rule has to be broken when there is an odd number of teams in a scoring group. In that case the last/bottom team in a group is paired with the top team in next lower scoring group. 3. In the same scoring group the teams are divided into two halves - top and bottom. In chess this is done based on player's rating. In bridge we could do it if there is any seeding order but I believe it is random in ACBLscore. #1 in top half is paired with #1 in bottom half, #2 vs. #2 etc. If the two team have played each other, then switch the bottom group one to the next team. In chess there is also color assignment that makes it more complicated, but it has rules to use exchange (swap two players) and mutation (reorder a subgroup of players) to get a possible pairing.

In chess each game score only has three possibilities: win(1), lose (0) and draw(0.5). So there are a lot of players tied with the same score every round and it needs these rules to do pairing. In bridge each round score could be from 0 or 20(30). So the chance of tie is much smaller and it should be simpler to pair.

The requirement to do pairing with partial score is a challenge. Some possible solutions are a. Check the top teams and bottom teams first. If there are no teams (in play) that could have scores higher than two top scored teams (already reported), then pair these two team for next round. Similarly it could be done for the bottom teams if there are even number of teams. If it is odd number of teams, you need find three lowest scores for three way. b. For other teams in the middle, if there are three teams with the same score, pick two of them to pair for next round.

At any time in this partial pairing the program needs to check the teams still in play and unpaired teams to make sure there is no team that has played against all other teams. This is necessary to follow rule #1. In practice if the above partial pairing is too slow in producing pairing, it might need to relax rule #2 to treat teams with score difference of 1 VP (or some other number) as same score in order to speed up pairing.

You are ignoring the author of this comment. Click to temporarily show the comment.

Warren Buffet said he likes to invest in company with simple business model that it could be run by a monkey, because “sooner or later it will be run by a monkey”. We have a lot of speculation about why ACBL made this decision but I have a feeling this is what happened. This also reminded me a history in not too distant past. In early 1990s US decided to build a Superconductor Super Collider after many committee reviews that took over 5 years. It spent 1-2B USD to dig a tunnel in Texas. Then Clinton and a new congress came to power. They decided to cancel the project. History likes to repeat itself, in large or small scale.

You are ignoring the author of this comment. Click to temporarily show the comment.

Do we do know what is ACBL rule about Swiss team pairing. FIDE and USCF all have very clear rule about chess pairing. I'm a chess tournament director and I know partial pairing is possible even though chess pairing is more complicated than bridge. As you point out chess also has color assignment and it adds another constraint. There are some difference in bridge vs chess. In chess you give a bye to lowest ranked player when there is odd number of player. In bridge, you need pair a three-way for two round with odd number of teams. The rest of them are standard. In principal a Swiss pairing algorithm is not difficult to work out. For a given round where team score/standing is s(i), the next round pair should minimize S = sum(|s(i)-s(j)|) with constraint i and j has not played. Given the current computing power one could even use brutal force to solve it. If you want a smart algorithm, you could define the pair logic as how to divide a group of teams into two groups and both of them are pairable. A group is not pairable if one team has played against all other teams. This call could be recursive. You could start from the standard Swiss pairing requirement to group team with same score from top down. The tricky part for Swiss pairing is about handling a large number of teams but the difference between number of team and number of round is small. When Num of round = Num of teams - 1, it becomes a round robin and the algorithm need to look ahead of future round of pairing. For example, a 7 team Swiss with 6 round, one of them needs to play all 6 round with three-ways. If you mistakenly take 3 teams that has not played for three way in round 1 and 2 to play three way for round 3 and 4, you'll find out you could not find a possible three way for round 5 and 6. One factor that makes bridge Swiss pairing easier than chess is that it may not have a lot of tie in score that your need to use rating (or other seeding) information. With either 20 and 30 VP scale, especially the new fractional VP score, the chance for teams with tie is smaller chess and it is easier to apply standard Swiss rule. Chess tournament also has some special rules for last round. If a tournament has multiple class prizes, the last round pairing would prefer to pair players within their own class. Bridge should also have a preference to pair teams with same stratum. Finally I have a suspicion that when ACBLscore pair the next round with partial scores, it may not follow the standard Swiss pairing rule to pair teams with exact same scores. It might treat score difference of 1 or 2 VP as equal to get the pairing speed up. This is just my guess.

You are ignoring the author of this comment. Click to temporarily show the comment.

I agree this Open Source should be a topic of itself. However I think the potential users are not bridge players but bridge software developers. Bridge players does not have any interest in what language the software is written or it is open source or not, as long as it works. Software developers do.

If we are talking about Open Source, I think we should go beyond ACBLScore. There is clearly a need to have some “industry standard” in bridge software. For example, it is best to define some standard “game file format” so some common data from a tournament could be saved. This goes beyond ACBL tournaments and bridge software for other country could use it as well. Other package that could be included in open source are double dummy analysis, Swiss/KO team pairing, pair game movement and rating system etc.

What this open source project would do is that it allows software developers to develop their own application for specific purpose without rewriting the basic business logic covered by open source. I noticed that one of the requirement for ACBLScore+ is that it needs to do everything ACBLScore does. So it needs to rewrite all pairing and movement logic in another language. With open source, it could simply just use the code from open source project. ACBL developers only need to develop its own features to do financial report, how to award master points etc. These code are application specific and not open sourced.

You are ignoring the author of this comment. Click to temporarily show the comment.

The other question is how much it is going to cost to “enhance” current system. I suppose it is not going to be free even they bring it “in house”? By the way how many software developers are there on ABCL payroll now and what are they doing?

You are ignoring the author of this comment. Click to temporarily show the comment.

I found the following link from Bridgescore+ that has Mr. Hartman's story about the contract dispute with ACBL that led to the breakdown of negotiation. http://bsp.bridgescoreplus.com/?page_id=51

Ping Hu

Ping Hu

Ping Hu

Ping Hu

I think a better way is to get most updated game results from Bridgemate. For most unfinished matches, they should be on the last board. Bridgemate should have all other game results and you could make a very good guess of what match results should be (unless there is big swing on last board). Even you are off by 1 or 2 VP if may not make any differences in pairing results. Of course you could still apply your simulation for these last board results but is would be more manageable.

Ping Hu

Ping Hu

What it needs is a real rating system that measures playing ability. There were a couple other threads about this topic recently.

Ping Hu

Ping Hu

PAIRING

1. For the first match of the event, entries will be sold by random

draw (The sponsoring organization may elect to seed the first

match.*). If teams remain without opponents at game time these

teams will be matched as follows: the team with the highest team

number will be reassigned to play the team with the lowest team

number and so on as necessary. When only one such team remains,

that team will play in a three-way match including the two teams

with the nearest team numbers. * This includes, for the first

match, pairing A strat vs A strat, etc. as possible.

2. For each subsequent match, pairings will be assigned (within

groups of teams) such that: a) no two teams shall meet twice in

the event, and, b) 1. each team shall meet a team whose current

record is as close to its own as possible, or 2. for an event with

an even number of entries ONLY (i.e., no three-way matches):

randomly pair teams for their second round match. For the

remainder of the first session or one-half the total number

matches (rounded down)each team shall meet a team whose record

after the previous match is as close to its own as possible.

Current record must be used for the final session or for the last

one-half of the total number of matches (rounded up).

3. If only one team is leading, random draw shall determine which of

its equally eligible opponents it meets. With teams tied for the

lead, pairings shall be such that as many of the tied teams play

each other as possible. This procedure shall be repeated for all

teams still eligible to finish in the overall ranking.

Ping Hu

Ping Hu

Ping Hu

Ping Hu

Ping Hu

There are a few rules in Swiss pairing.

1. No teams should be paired twice. This is a hard rule. It could only be broken when the number of rounds equal or greater than number of teams.

2. Teams with same score should be paired together. This rule has to be broken when there is an odd number of teams in a scoring group. In that case the last/bottom team in a group is paired with the top team in next lower scoring group.

3. In the same scoring group the teams are divided into two halves - top and bottom. In chess this is done based on player's rating. In bridge we could do it if there is any seeding order but I believe it is random in ACBLscore. #1 in top half is paired with #1 in bottom half, #2 vs. #2 etc. If the two team have played each other, then switch the bottom group one to the next team. In chess there is also color assignment that makes it more complicated, but it has rules to use exchange (swap two players) and mutation (reorder a subgroup of players) to get a possible pairing.

In chess each game score only has three possibilities: win(1), lose (0) and draw(0.5). So there are a lot of players tied with the same score every round and it needs these rules to do pairing. In bridge each round score could be from 0 or 20(30). So the chance of tie is much smaller and it should be simpler to pair.

The requirement to do pairing with partial score is a challenge. Some possible solutions are

a. Check the top teams and bottom teams first. If there are no teams (in play) that could have scores higher than two top scored teams (already reported), then pair these two team for next round. Similarly it could be done for the bottom teams if there are even number of teams. If it is odd number of teams, you need find three lowest scores for three way.

b. For other teams in the middle, if there are three teams with the same score, pick two of them to pair for next round.

At any time in this partial pairing the program needs to check the teams still in play and unpaired teams to make sure there is no team that has played against all other teams. This is necessary to follow rule #1. In practice if the above partial pairing is too slow in producing pairing, it might need to relax rule #2 to treat teams with score difference of 1 VP (or some other number) as same score in order to speed up pairing.

Ping Hu

This also reminded me a history in not too distant past. In early 1990s US decided to build a Superconductor Super Collider after many committee reviews that took over 5 years. It spent 1-2B USD to dig a tunnel in Texas. Then Clinton and a new congress came to power. They decided to cancel the project. History likes to repeat itself, in large or small scale.

Ping Hu

I'm a chess tournament director and I know partial pairing is possible even though chess pairing is more complicated than bridge. As you point out chess also has color assignment and it adds another constraint. There are some difference in bridge vs chess. In chess you give a bye to lowest ranked player when there is odd number of player. In bridge, you need pair a three-way for two round with odd number of teams. The rest of them are standard.

In principal a Swiss pairing algorithm is not difficult to work out. For a given round where team score/standing is s(i), the next round pair should minimize S = sum(|s(i)-s(j)|) with constraint i and j has not played. Given the current computing power one could even use brutal force to solve it.

If you want a smart algorithm, you could define the pair logic as how to divide a group of teams into two groups and both of them are pairable. A group is not pairable if one team has played against all other teams. This call could be recursive. You could start from the standard Swiss pairing requirement to group team with same score from top down.

The tricky part for Swiss pairing is about handling a large number of teams but the difference between number of team and number of round is small. When Num of round = Num of teams - 1, it becomes a round robin and the algorithm need to look ahead of future round of pairing. For example, a 7 team Swiss with 6 round, one of them needs to play all 6 round with three-ways. If you mistakenly take 3 teams that has not played for three way in round 1 and 2 to play three way for round 3 and 4, you'll find out you could not find a possible three way for round 5 and 6.

One factor that makes bridge Swiss pairing easier than chess is that it may not have a lot of tie in score that your need to use rating (or other seeding) information. With either 20 and 30 VP scale, especially the new fractional VP score, the chance for teams with tie is smaller chess and it is easier to apply standard Swiss rule.

Chess tournament also has some special rules for last round. If a tournament has multiple class prizes, the last round pairing would prefer to pair players within their own class. Bridge should also have a preference to pair teams with same stratum.

Finally I have a suspicion that when ACBLscore pair the next round with partial scores, it may not follow the standard Swiss pairing rule to pair teams with exact same scores. It might treat score difference of 1 or 2 VP as equal to get the pairing speed up. This is just my guess.

Ping Hu

If we are talking about Open Source, I think we should go beyond ACBLScore. There is clearly a need to have some “industry standard” in bridge software. For example, it is best to define some standard “game file format” so some common data from a tournament could be saved. This goes beyond ACBL tournaments and bridge software for other country could use it as well. Other package that could be included in open source are double dummy analysis, Swiss/KO team pairing, pair game movement and rating system etc.

What this open source project would do is that it allows software developers to develop their own application for specific purpose without rewriting the basic business logic covered by open source. I noticed that one of the requirement for ACBLScore+ is that it needs to do everything ACBLScore does. So it needs to rewrite all pairing and movement logic in another language. With open source, it could simply just use the code from open source project. ACBL developers only need to develop its own features to do financial report, how to award master points etc. These code are application specific and not open sourced.

Ping Hu

Ping Hu

Ping Hu

Ping Hu

http://bsp.bridgescoreplus.com/?page_id=51