[nickxyzt]

Hi,

Statistics say:
- 25+HCP => a game is possible with >50% chances
- 33+HCP => a small slam is possible with >50% chances
- 37+HCP => a big slam is possible with >50% chances.

My question is: did anybody actually made this analysys on a computer, or is it just a feeling based on experience?

I plan to create a computer program to play all the possible hands (yes, all the 13 millions) in all the possible ways, and show the results based on how many HCP an axis has.

I just don't want to reinvent the wheel, so if anybody is aware of anything similar, please tell me.

Thanks!

[helene_t]

There are a lot more than 13 million hands. You cannot possibly analyse all hands, no matter how cool your computer is!

For the purpose of finding the probability of making small slam with, say, 33 HCPs, some 1000 hands would be enough for a reasonably accurate estimate (assuming you select only hands with 33 HCPs), but there are a number of issues:
- how do you assume the hands will be played? The simplest is a double-dummy simulation, i.e. assuming all four players play optimally, being able to see all four hands. This will give declarer an advantage in the slam zone, though. Alternatively, use GIB or some similar software. But that raises the issue of which information is available to the defenders from the bidding.
- not all hands with 33 HCPs would realistically bid 6NT. With a fit, a small slam (or big slam) in a suit may be a more realistic outcome of the auction. And with AK in a suit missing, sometimes that would be discovered during the auction.

[nigel_k]

You aren't going to be able to create a computer program to play all the possible hands in all the possible ways. Not one that will finish in our lifetimes anyway. Or maybe it will finish when you are 73 years old but you find a bug and have to rerun it.

If you do it by random sampling, then the 25 HCP rule is really only good when both hands are balanced. I've found that 24 HCP is just barely enough for 3NT double dummy when vulnerable at IMPS with two balanced hands, and 25 is needed otherwise.

For slams, Helene is right that double dummy analysis is off by quite a lot as declarer has most of the guessing to do. You might find that two balanced hands with 31 HCP make 6NT more than half the time double dummy, but they won't in real life.

I'm not sure whether double dummy analysis favours declarer or defence at the game level but I think it is quite close.

[matmat]

nickxyzt, on Jul 27 2010, 07:42 AM, said:

I plan to create a computer program to play all the possible hands (yes, all the 13 millions) in all the possible ways, and show the results based on how many HCP an axis has.

My first suggestion would be to calculate the actual number of possible deals.

My second suggestion would be to multiply that number by 0.01 seconds per hand analysis and convert that time into years to decide whether such a computation is possible.

[nickxyzt]

Ok.

I've just calculated the number of possible distributions:
53,644,737,765,488,792,839,237,440,000

It has 29 digits. Assuming that I plan to finish in a year (with a computer working 24/24), the number of analysed distributions per second should be
1,701,063,475,567,249,899,772.

So this is not even eligible for creating a distributed screen saver...

My idea was to create a database with these distributions and to adjust my bidding system. But it seems that I will do it anyway, with random distributions. The issue is with the random numbers on computers, which are not exactly random numbers...

Thank you all for your answers!

[helene_t]

nickxyzt, on Jul 28 2010, 07:25 AM, said:

The issue is with the random numbers on computers, which are not exactly random numbers...

Nah you shouldn't worry about that. There are pretty good random number generators around.

The problem is how to decide how many tricks human players are likely to make on a given deal. That's not trivial for a computer.

[nickxyzt]

Well... I don't plan to decide how many tricks a human play is likely to make.
I plan to decide the best play by the declarer no matter how the opponents play, which is easy to calculate (by brute-forcing all the possible plays).

[helene_t]

There are too many ways to play a hand. Writing an effective double dummy solver is not a trivial task. You may want to google on double dummy solver. There is some neat software, some of it is free.

You can also just download the GIB double dummy database. It contains 700,000 random hands, solved in all five strains with all four hands as declarer, i.e. in total 20 DD analysis results per hand. I think 700,000 is enough for many statistical projects, although it doesn't suffice if you are interested in very specific questions, for example concerning a particular hand.

[nigel_k]

You can write a completely brute force double dummy solver quite easily but it will not run in decent time. You need to code in short cuts that will speed it up a lot and have either zero or near zero chance of affecting the result. Which short cuts to code for is not that easy to work out.

[dake50]

I agree your frustration. Some 80+years ago, bridge nabobs(Ely, Charles) speculated opening bid, game, slam, partial, penalty double. Has this been checked with the massive computing power now available? Should be decades already done!
Agree helene_t, GIB gets most comparisons (eg. 1N: 12-14 OR 15-17) accurate to 1::1000+. That's "what's in the cards". The challenge is how close to "what's in the cards" one's bidding system gets.

[wyman]

nickxyzt, on 2010-July-28, 00:25, said:

Ok.

I've just calculated the number of possible distributions:
53,644,737,765,488,792,839,237,440,000

It has 29 digits. Assuming that I plan to finish in a year (with a computer working 24/24), the number of analysed distributions per second should be
1,701,063,475,567,249,899,772.

So this is not even eligible for creating a distributed screen saver...

My idea was to create a database with these distributions and to adjust my bidding system. But it seems that I will do it anyway, with random distributions. The issue is with the random numbers on computers, which are not exactly random numbers...

Thank you all for your answers!

nickxyzt, on 2010-July-28, 05:18, said:

Well... I don't plan to decide how many tricks a human play is likely to make.
I plan to decide the best play by the declarer no matter how the opponents play, which is easy to calculate (by brute-forcing all the possible plays).

http://en.wikipedia....orial_explosion

http://en.wikipedia....per_instruction

http://en.wikipedia....wiki/Clock_rate

http://en.wikipedia.org/wiki/Hertz

http://wiki.answers....conds_in_1_year

These would be a good start.

[Free]

nickxyzt, on 2010-July-28, 00:25, said:

Ok.

I've just calculated the number of possible distributions:
53,644,737,765,488,792,839,237,440,000

It has 29 digits. Assuming that I plan to finish in a year (with a computer working 24/24), the number of analysed distributions per second should be
1,701,063,475,567,249,899,772.

So this is not even eligible for creating a distributed screen saver...

My idea was to create a database with these distributions and to adjust my bidding system. But it seems that I will do it anyway, with random distributions. The issue is with the random numbers on computers, which are not exactly random numbers...

Thank you all for your answers!

That is not 100% correct. Out of the 53,644,... hands you could scratch 75% because all hands appear 4 times (rotated). However that's still too much for practical use.

Oh, and you actually can generate true random numbers with a computer, so that statement is not correct either!

[paulg]

Free, on 2010-October-21, 03:17, said:

Oh, and you actually can generate true random numbers with a computer, so that statement is not correct either!

HotBits: Genuine random numbers, generated by radioactive decay
http://www.fourmilab.ch/hotbits/