[gordontd]

pran, on Dec 6 2009, 04:46 PM, said:

This is a shocking allegation.

I'm not sure why you are shocked by the idea that a program crash will produce uncertain results that need to be checked.

[suokko]

gordontd, on Dec 6 2009, 07:29 PM, said:

pran, on Dec 6 2009, 04:46 PM, said:

This is a shocking allegation.

I'm not sure why you are shocked by the idea that a program crash will produce uncertain results that need to be checked.

Because they shouldn't! It is bug that program crashes in first place. There is 2nd bug that program doesn't handle crash correctly.

[McBruce]

Surely when you ask the dealing program to produce a set of deals it will either respond "DONE" or send you some error message. If the former, you take the file to the machine and start the dealing of the actual cards; if the latter, you regenerate a new set of hands, don't you?

"Computer-dealt hands at a club" and "the computer dealt the same hand twice" can mean several similar but different things. I'm assuming from David's post that the hand records for the set included the two consecutive deals with all four hands the same but rotated. I think in that case these are two different deals (albeit remarkably similar) but agree that the coincidence strongly suggests that the software needs to be looked at.

But it could also mean that the computer dealt the same hand twice and there was an error by the person who took the cards from the dealing machine and put them in the slots. Once you add the human factor there is no limit to what can happen. I was called to the table in a Swiss Teams (player-dealt hands) recently to find a player debating with himself whether AJJ97 was a biddable spade suit.

[jeremy69]

If you haven't got time to investigate (and finding out who played board 10 before 9 may not be so easy) then
1. You will beat up the software (and/or it's owner) after the event
2. You will remonstrate with the player if he announced it in such a way as to poison the board for others (but not if he told you quietly)
3. You will direct that the boards continue to be played because you have no evidence that this is other than a correct deal (although I agree probability is on the side of suspicion).

[mjj29]

pran, on Dec 6 2009, 10:46 AM, said:

And what does it take to test a card dealing program? A set of 8000 deals run through my testing procedure will give an initial answer within seconds. More such sets created independently over some time and tested will usually be sufficient to provide a definite answer, but preferably the basic random generator algorithm should also be available for a separate test as this is the kernel of any such system.

Seriously, how hard is it to write a random board generating algorithm. Every programming language has a library for getting good (secure) random numbers, plug that into a Knuth shuffle and you're done... Seeding it isn't a problem either, the platform should have a way of randomly initializing the seed each time.

Out of interest what's your testing procedure?

[aguahombre]

jeremy69, on Dec 6 2009, 10:46 AM, said:

2. You will remonstrate with the player if he announced it in such a way as to poison the board for others (but not if he told you quietly)
3. You will direct that the boards continue to be played because you have no evidence that this is other than a correct deal (although I agree probability is on the side of suspicion).

I do hope this is tongue-in-cheek.

[pran]

mjj29, on Dec 6 2009, 07:44 PM, said:

pran, on Dec 6 2009, 10:46 AM, said:

And what does it take to test a card dealing program? A set of 8000 deals run through my testing procedure will give an initial answer within seconds. More such sets created independently over some time and tested will usually be sufficient to provide a definite answer, but preferably the basic random generator algorithm should also be available for a separate test as this is the kernel of any such system.

Seriously, how hard is it to write a random board generating algorithm. Every programming language has a library for getting good (secure) random numbers, plug that into a Knuth shuffle and you're done... Seeding it isn't a problem either, the platform should have a way of randomly initializing the seed each time.

Out of interest what's your testing procedure?

1: Good random number generators are not common although they have certainly become better over the years. I don't know if Microsoft Excel still uses a 16 bits generator or if they at last have advanced to 32 bits.
The size of the generator is directly limiting the number of deals that can safely be generated with that generator. A 16 bits generator is "safe" for only about 12 deals in a run.

Delphi (the language I use) includes a good 32 bits generator, but I have implemented my own 64 bits generator based on the recommendation by Knuth.
(At present I am testing out a generator where I can select the size to any number of bits I want.)

2: For seeding the only really important issue is to guarantee that two different runs can never start with the same seed. In addition all the seed bits should be created randomly. This is not usually secured by any platform that I know of.

3: My test procedure is to apply Chi-square analysis on hand distributions, suit distributions, High card point distributions and individual card distributions over series of (typically) 800 deals. Each Chi-Sq value is transformed into the probability that a true random set would be closer to the theoretical average than the observed distribution.

The most "expected" result is of course 50% indicating that a closer to average result is just as probable as a less close result.

But the really important test is that over ten such test series (each with 800 deals) the probabilities should spread fairly evenly between 0 and 100%

A consistently low probability is a danger signal, it is like a dice which when thrown many times will yield exactly one each of the numbers from 1 thru 6 for each 6 throws, or six dice when thrown will show a straight on (nearly) each throw, a very unlikely event.

A consistently high probability is another danger signal. Last time I observed that was with a card dealing program that gave the ♣2 to the same hand in almost every deal.

I have selected the size of a test set 800 deals rather arbitrarily, but it should not be less, or the Chi-Sq tests will be significant for only the most common distributions.

[nige1]

blackshoe, on Dec 6 2009, 10:13 AM, said:

On what legal grounds do you issue such a warning, Nigel? Did he do something wrong?

Under what law, can you object to consecutive identical hands?

Obviously, from the point of view of the player, who calls the director, this deal might be similar to but not the same as the previous deal. The unseen cards may be quite differently distributed. His claim that his hand is similar to his previous hand is gratuitous unauthorised information. He can wait until the play is over.

[nige1]

I believe that Thomas Andrews' dealing program will generate all possible hands (eventually). Richard Pavlicek's dealer is similarly excellent and fast. They both have all kinds of fascinating stuff!

[aguahombre]

nige1, on Dec 6 2009, 01:21 PM, said:

blackshoe, on Dec 6 2009, 10:13 AM, said:

On what legal grounds do you issue such a warning, Nigel? Did he do something wrong?

Under what law, can you object to consecutive identical hands?

Obviously, from the point of view of the player, who calls the director, this deal might be similar to but not the same as the previous deal. The unseen cards may be quite differently distributed. His claim that his hand is similar to his previous hand is gratuitous unauthorised information. He can wait until the play is over.

Why do you keep going there? The same hand was rotated counter-clockwise. that is a "given". How else should the OP say it, and in what different ways, before the fact is established?

Keeping both boards in play is not bridge as I know it. People with the appropriate skill set will know the hand, especially RHO's hand while attempting to bid, play, defend or whatever. Others will not.

Get over the fact that one astute player drew attention to the problem. That player is not the problem. My partner and I were the first to report that two different boards were identical at the start of the fifth round of a top flight regional scored across multi sections ---resulting in a chinese fire drill of scoring that you would not believe. But not once did anyone suggest we should have kept our mouths shut so both boards could continue to be played. And no one was silly enough to suggest it was just a miracle of random number selection.

[mjj29]

pran, on Dec 6 2009, 02:23 PM, said:

1: Good random number generators are not common although they have certainly become better over the years. I don't know if Microsoft Excel still uses a 16 bits generator or if they at last have advanced to 32 bits.
The size of the generator is directly limiting the number of deals that can safely be generated with that generator. A 16 bits generator is "safe" for only about 12 deals in a run.

Well, that suggests using a LFSR or similar, which will, obviously, loop after it's width. However, that won't actually give you completely independent deals, since it _can't_ repeat until the end. Surely you want to re-seed each board (this is, infact, what I do). There are a number of good ways to generate a cryptographically secure bitstream from a seed, AES256 in CTR mode with a random key being quite a good one.

pran, on Dec 6 2009, 02:23 PM, said:

Delphi (the language I use) includes a good 32 bits generator, but I have implemented my own 64 bits generator based on the recommendation by Knuth.
(At present I am testing out a generator where I can select the size to any number of bits I want.)

A use Java's SecureRandom class re-seeded from the host's entropy pool each board, using just the low-order 6 bits as the input of a Knuth shuffle. I believe this to be both statistically flat and cryptographically secure.

pran, on Dec 6 2009, 02:23 PM, said:

2: For seeding the only really important issue is to guarantee that two different runs can never start with the same seed. In addition all the seed bits should be created randomly. This is not usually secured by any platform that I know of.

/dev/urandom on anything other than windows for a start.

Anyway, I think we've probably side-tracked this thread enough

[helene_t]

pran, on Dec 6 2009, 08:23 PM, said:

Last time I observed that was with a card dealing program that gave the ♣2 to the same hand in almost every deal.

I think I know that program. Not sure how it manages to get that wrong. One of the first computer programs I wrote when my dad took an office compute home for me and my brother to play with was a dealing prgram that would usually give ♠AK to the same player, as it allocated each card randomly among the non-filled hands, instead of weighting them by their numbers of empty slots.

[blackshoe]

nige1, on Dec 6 2009, 03:21 PM, said:

Under what law, can you object to consecutive identical hands?

Under what law can you not?

Quote

Obviously, from the point of view of the player, who calls the director, this deal might be similar to but not the same as the previous deal. The unseen cards may be quite differently distributed. His claim that his hand is similar to his previous hand is gratuitous unauthorised information. He can wait until the play is over.

I disagree. It might be "better", for some values of "better", if he had waited, but there is no law requiring him to do so.

The relevant law is 9A1. Gtanted, 9A1 refers to unnamed other laws which may prohibit the director call. Fair enough. Find one.

[nige1]

Hans van Staveren's Big deal uses 96 bits to ensure that his random number generator can produce enough numbers and uses Thomas Andrews' algorithm to map each number to a deal (ensuring every possible deal is accessible).

[pran]

helene_t, on Dec 6 2009, 11:35 PM, said:

pran, on Dec 6 2009, 08:23 PM, said:

Last time I observed that was with a card dealing program that gave the ♣2 to the same hand in almost every deal.

I think I know that program. Not sure how it manages to get that wrong. One of the first computer programs I wrote when my dad took an office compute home for me and my brother to play with was a dealing prgram that would usually give ♠AK to the same player, as it allocated each card randomly among the non-filled hands, instead of weighting them by their numbers of empty slots.

Classic and well known mistake.

So in your program you started with placing the ♣2 and ended with placing the ♠A?

[pran]

nige1, on Dec 7 2009, 12:06 AM, said:

Hans van Staveren's Big deal documentation shows you why you need 96 bits to ensure that no deal is inaccessible and uses Thomas Andews' algorithm to identify each deal.

I know about BigDeal and the fallacy in showing how you need a 96 bits random generator. (Yes, there is a fallacy there!)

[nige1]

nige1, on Dec 6 2009, 01:21 PM, said:

Obviously, from the point of view of the player, who calls the director, this deal might be similar to but not the same as the previous deal. The unseen cards may be quite differently distributed. His claim that his hand is similar to his previous hand is gratuitous unauthorised information. He can wait until the play is over.

aguahombre, on Dec 6 2009, 04:11 PM, said:

Why do you keep going there? The same hand was rotated counter-clockwise.  that is a "given".  How else should the OP say it, and in what different ways, before the fact is established?  Keeping both boards in play is not bridge as I know it.  People with the appropriate skill set will know the hand, especially RHO's hand while attempting to bid, play, defend or whatever.  Others will not. Get over the fact that one astute player drew attention to the problem.  That player is not the problem. My partner and I were the first to report that two different boards were identical at the start of the fifth round of a top flight regional scored across multi sections ---resulting in a chinese fire drill of scoring that you would not believe.  But not once did anyone suggest we should have kept our mouths shut so both boards could continue to be played.  And no one was silly enough to suggest it was just a miracle of random number selection.

blackshoe, on Dec 6 2009, 05:56 PM, said:

I disagree (with nigel). It might be "better", for some values of "better", if he had waited, but there is no law requiring him to do so.
The relevant law is 9A1. Gtanted, 9A1 refers to unnamed other laws which may prohibit the director call. Fair enough. Find one.

Its no big deal Blackshoe and Aquahombre

I imagined that, in the middle of a hand, saying that you hold the same cards as on the previous deal, might be construed as unauthorised information to partner. I'm not a director and bow to your superior knowledge

[nige1]

helene_t, on Dec 6 2009, 05:35 PM, said:

I think I know that program. Not sure how it manages to get that wrong. One of the first computer programs I wrote when my dad took an office compute home for me and my brother to play with was a dealing prgram that would usually give ♠AK to the same player, as it allocated each card randomly among the non-filled hands, instead of weighting them by their numbers of empty slots.

Computer Weekly challenged readers to deal hands in the early 70's. I wrote a simple program like Helen_t's that Ian Morrison used to deal hands for Scottish national competitions. A colleague published my sampling algorithm in CACM . but modern programs (eg Thomas Andrews, Richard Pavlicek, and Hans van Staveren) are much better.

[suprgrover]

pran, on Dec 6 2009, 06:42 PM, said:

I know about BigDeal and the fallacy in showing how you need a 96 bits random generator. (Yes, there is a fallacy there!)

Could you explain what you mean here? There are between 2^95 and 2^96 possible bridge deals, so what is wrong with using 96 bits?

[suokko]

mjj29, on Dec 6 2009, 08:44 PM, said:

pran, on Dec 6 2009, 10:46 AM, said:

And what does it take to test a card dealing program? A set of 8000 deals run through my testing procedure will give an initial answer within seconds. More such sets created independently over some time and tested will usually be sufficient to provide a definite answer, but preferably the basic random generator algorithm should also be available for a separate test as this is the kernel of any such system.

Seriously, how hard is it to write a random board generating algorithm. Every programming language has a library for getting good (secure) random numbers, plug that into a Knuth shuffle and you're done... Seeding it isn't a problem either, the platform should have a way of randomly initializing the seed each time.

Out of interest what's your testing procedure?

Too bad secure random number generator is often hidden so I would suspect normal bridge dealer use simple rand() call. Quality of rand is platform depend but often it is optimized for speed instead of quality of bit stream. Luckily new c++ standard will provide better random number library that provides multiple random number generators with different qualities and speeds. (But none that is cryptographically)

In windows secure random number api is hidden in crypto api which is probably not know to many programmers except when writing some crypto programs. You already mentioned the unix world /dev/random that would provide really independent bit stream.

Problem for using non-windows platform is that wireless bridge scoring systems are only supported in windows so directors are using windows for everything.