Deal and the GIB DD library

[helene_t]

I downloaded the binary (library.dat) version of the GIB DD database. Can't find it anymore, donno if it has been moved to some other server or if it isn't available anymore (made obsolete by the GNU license for "deal".

 

l never managed to decode it, though. Under windows, there seemed to be a frame shift somewhere which made all but the first few hundred records corrupt. Under linux, that frame sihift did not appear for some reason (does this make sense?), but I have problems with the byte order. After half a day of detective work I managed to decode the deal part of it, but the DD analysis part of it still doesn't make too much sense.

 

Does anybody have a c or c++ routine that can read the records? The result of my detective work is at the end of this post, but as said the "tricks" field does not seem to be correct.

 

Then the "deal" program". The makefile does not work under Ubuntu. I made the following changes:

- removed the target specification "counttable" in Makefile

- changed the include of "tcl.h" to <tcl.h> in deal.h

- linked "deal" manually with tcl8.4.so.0

 

Now it works! I'm so proud everytime I manage to get something working under Linux :P It is really cool, I plan to make a lot of crazy statistical analysis based on it and post the results on this forum :)

=========================================================================

typedef struct {

long suits[4];

short tricks[5];

} inprectype;

 

char directionsymbols[4] = "WNES";

char denominationsymbols[5] = "nshdc";

char cardsymbols[15] = "0023456789TJQKA";

 

void readrec ( char *buf, inprectype *res ) {

int suit, denom;

char *buf2= (char*)res;

for(suit=0; suit<4; suit++) {

buf2[3]=buf[0];

buf2[2]=buf[1];

buf2[1]=buf[2];

buf2[0]=buf[3];

buf=&buf[4];

buf2=&buf2[4];

};

for(denom=0;denom<5; denom++) {

buf2[1] = buf[0];

buf2[0] = buf[1];

buf=&buf[2];

buf2=&buf2[2];

};

};

 

#define getplayer(inputrec,suit,card) (3 & ((inputrec->suits[suit]>>(28-2*card))))

void getsuit(inprectype *inprec, long player, int suit, char *res) {

int card;

// printf("getsuit:");

for(card=14;card>1;card--) {

// printf(" %d", 3 & (inprec->suits[suit]>>(2*card+2)));

if(getplayer(inprec,suit,card) ==player) {

// if((3 & ((inprec->suits[suit]>>(28-2*card)))) ==player) {

*res = cardsymbols[card];

res=&(res[1]);

};

};

*res = '\0';

// printf("\n");

};

 

int getsuitlen(inprectype *inprec, long player, int suit) {

int card;

int res=0;

for(card=14;card>1;card--) if(getplayer(inprec,suit,card) ==player) res++;

return res;

};

[CarlRitner]

I have a document that explains how this is encoded, if i can find it in the mess here. I know that the DD data is all referenced to south (how many tricks north-south take regardless of who is declarer) and it's held in 4-bit nibbles.

 

Here it is:

 

"The 5 16-bit integers indicate how many tricks can be taken by each player and in each denomination. The first integer refers to NT, and the subsequent ones to the suits. Bits 0-3 give the number of tricks that can be taken by NSwith player 0 (West) on lead; bits 4-7 the number that can be taken by NS with player 1 on lead, and so on."

 

The suit order is naturally SHDC. Each hand is 26 bytes

[helene_t]

I have a document that explains how this is encoded, if i can find it in the mess here. I know that the DD data is all referenced to south (how many tricks north-south take regardless of who is declarer) and it's held in 4-bit nibbles.

 

Here it is:

 

"The 5 16-bit integers indicate how many tricks can be taken by each player and in each denomination. The first integer refers to NT, and the subsequent ones to the suits. Bits 0-3 give the number of tricks that can be taken by NSwith player 0 (West) on lead; bits 4-7 the number that can be taken by NS with player 1 on lead, and so on."

 

The suit order is naturally SHDC. Each hand is 26 bytes

Tx Carl, but I already have that document. It's just that it doesn't work that way. Maybe it's a question of different byte order on different machines, maybe it's just that I (I'm not a computer scientist) don't know the byte-order conventions. As you see in my code I had to swap around a lot with the bytes to make it work for the deals, yet I haven't found the correct way to swap the "tricks" part of it.

 

So I really need c/c++ code.

[helene_t]

The bad news is that the deal/GIB interface works under windows only. So I can't use it.

 

But I solved the problem with the DD database. The gettricks function must be

int gettricks(inprectype *inprec, short player, int denom) {

if(player==3) player = -1;

return((inprec->tricks[denom] >> (4*(player+1))) & 15);

};

 

I solved this by finding the permustation of the chairs that gave the strongest correlation between declarer's HCPs and the number of tricks he can take in notrumps.

[CarlRitner]

The important (or quirky) thing about the trick data is that it's NOT how many tricks declarer can take; it's how many tricks North-South can take. This is true even when East or West is declaring, so 13-n must be applied for the EW cases.

 

But I'm sure you caught onto that as well.

[Free]

The important (or quirky) thing about the trick data is that it's NOT how many tricks declarer can take; it's how many tricks North-South can take. This is true even when East or West is declaring, so 13-n must be applied for the EW cases.

 

But I'm sure you caught onto that as well.

I can easily give you hands that E can make more tricks than W, that EW+NS tricks >13 or <13,... <_<

[CarlRitner]

That's true but does not invalidate anything I stated.

 

For each declarer case (20 in all) there are 13 tricks taken, some by NS and the rest by EW. The data in the record is always the NS data, so when North or South is the declarer, the number in the record is how many tricks for the declarer.

 

When East or West is the declarer, the number in the record is how many tricks the DEFENSE takes, since it's STILL NS data. To get the correct number for declarer, it's 13 minus that value.

 

Each of the 20 cases have exactly 13 tricks to be won.

[pdmunro]

Have you seen these?

 

http://web.telia.com/~u88910365/

 

http://www.df7cb.de/blog/tag/bridge.html

 

http://www.bridgemate.net/downloadDD.html

 

I use the last link (bridgemate). It accepts BBO files. It seems much quicker than GIB.

[helene_t]

Wow this is cool! Tx a lot, pdmunro!