The problem here is that a major part of bridge is legal collusion. That is what the bidding system is all about. Long-time partners pick up on all kinds of secondary signals and thus play better. In tournament play, the collusion is regulated to the extent that if you are going to play with a particular signalling system in the bid stage, you have to disclose which system you are using. So the problem is to detect where the collusion is beyond the legal bounds.
Moreover, there is potential for players to collude with non-partners as well as with partners. On Sat, Apr 28, 2012 at 6:22 PM, Sean Owen <[email protected]> wrote: > If there's no fraud, the win rate should be the same on deals that had > been played before, as on those that have not been played before. > > You have wins/losses on previously-played games, and wins/losses on > new games. Those are the ratios you're testing. > > On Sat, Apr 28, 2012 at 7:09 PM, Frank Scholten <[email protected]> > wrote: > > I have a question about computing the loglikelihood scores for this > problem. > > > > In bridge, deals are reused inside a tournament. > > > > I can see how to figure out which players play more against a specific > > partner than others. In this case N equals the number of deals, k11 > > from the loglikelihood contingency table equals the number of deals > > played by players A and B, k12 deals played by A but not by B, and so > > on. > > > > What I really want is to figure out which players have a lot of wins > > from deals that were played by others at the same time or in the past. > > The reasoning is that players who have wins only when someone else has > > played this deal before are suspect. > > > > However how do I account for this temporal aspect, 'number of won > > deals which were played before by player X' into the loglikelihood > > counts? It seems I have several subsets, like wins and losses, wins > > before a certain time and so on. > > > > I am not sure how to work these factors into a loglikelihood ratio > > test. Perhaps there is a different, more suitable method for this type > > of problem? > > > > Cheers, > > > > Frank >
