structure of DLM files
#1
Posted 2013-July-18, 12:26
I have noticed that there is a checksum and then some lines which look like:
Board 01=cgcajjjnakpkchipnjhmbmbpbh022
What's annoying is that these files always seem to go to 100 when we generate them and then our scoring program tries to find the optimal contract for all 100 boards even though we only need 27 I would like to know how this file is built up so I can edit it and perhaps write a script to throw out the "extra" boards that our Duplimate puts in it.
And as a bonus, try to figure out how I can read the cards from this piece of letter mess.
#2
Posted 2013-July-18, 12:49
Gerben42, on 2013-July-18, 12:26, said:
...
Board 01=cgcajjjnakpkchipnjhmbmbpbh022
...
And as a bonus, try to figure out how I can read the cards from this piece of letter mess.
Are there strings of 26 letters, each letter between a and p (16 letters)?
If each position in the string represents two cards C2,C3; C4,C5; C6,C7; ...
then the letter would tell you which two hands the two cards are in a=N,N b=N,E c=N,S upto p=W,W
?
Robin
"Robin Barker is a mathematician. ... All highly skilled in their respective fields and clearly accomplished bridge players."
#3
Posted 2013-July-18, 13:38
RMB1, on 2013-July-18, 12:49, said:
If each position in the string represents two cards C2,C3; C4,C5; C6,C7; ...
then the letter would tell you which two hands the two cards are in a=N,N b=N,E c=N,S upto p=W,W
?
Robin
That's great, thanks You don't happen to know how to build the checksums as well?
#4
Posted 2013-July-18, 13:45
As for tv, screw it. You aren't missing anything. -- Ken Berg
I have come to realise it is futile to expect or hope a regular club game will be run in accordance with the laws. -- Jillybean
#5
Posted 2013-July-18, 14:28
RMB1, on 2013-July-18, 12:49, said:
If each position in the string represents two cards C2,C3; C4,C5; C6,C7; ...
then the letter would tell you which two hands the two cards are in a=N,N b=N,E c=N,S upto p=W,W
?
Robin
I think it starts at the other end, with SA, SK ...
London UK
#6
Posted 2013-July-18, 18:50
DLM is the easier format of the two to understand. It uses the Windows
INI text-based structure:
[SECTION]
KEY=VALUE
KEY=VALUE
.
.
.
[SECTION]
KEY=VALUE
.
.
If you're looking to decode it, everything you want is in the
[Document] section. The key fields you need are:
From Board=X
To Board=Y
Board NN=<board data><checksum>
There should be Y+1-X "Board NN" key/value lines.
<board data> is always 26 characters long. Each character is an
alphabetic letter between a and p, representing the numbers 1 to 16.
Each number encodes two hand positions (1="NN" through to 16 ="WW").
Once decoded, you have a 52 character string of hand positions
(N/E/S/W) that maps to a card deck, organised SHDC (4 x AKQJT98765432).
eg:
Board 01=jlifaelnecgmoldfjmcflinlap023
This decodes like this:
j l i f a e l n e c g m o l d f j m c f l i n l a p
SE SW SN EE NN EN SW WE EN NS ES WN WS SW NW EE SE WN NS EE SW SN WE SW
NN WW
And now you have the mapping between hands and cards.
I didn't work out the checksum (but I know both the board data and
board number are incorporated), but that's only critical if you're
trying to _write_ a DLM file.
#7
Posted 2013-July-19, 07:23
Gerben42, on 2013-July-18, 12:26, said:
I'm surprised by this. The information is in the dlm file as to how many boards have been used. Sounds like an issue with the scoring program rather than the dlm file format.
London UK
#8
Posted 2013-July-30, 17:01
Gerben42, on 2013-July-18, 13:38, said:
As I understand it, the "checksums" aren't proper checksums:
- There's a so-called “Checksum” field at the top of the file - I'm told it's just #Boards+1 if #Boards is even, but #Boards-1 otherwise!
- The two checksum digits at the end of each deal line are apparently just the deal number successively XOR-ed with each card coding - I've not attempted to verify this.
#9
Posted 2014-February-03, 07:27
PeterAlan, on 2013-July-30, 17:01, said:
- There's a so-called “Checksum” field at the top of the file - I'm told it's just #Boards+1 if #Boards is even, but #Boards-1 otherwise!
- The two checksum digits at the end of each deal line are apparently just the deal number successively XOR-ed with each card coding - I've not attempted to verify this.
Just tried to calculate checksums using the above then comparing with the original. The result for the board checksums is always 1 out from the original - ie last bit set in original => not set in mine and vice versa. In other words, the seed for the XOR checksum is 1, not zero. In the case of the main checksum it's just the XOR of the lowest and highest board no.
Also note that the individual board checksums are three digits not two. These digits are the decimal representation of the single byte checksum.
Keith
#10
Posted 2017-August-17, 20:58
writerman, on 2014-February-03, 07:27, said:
Also note that the individual board checksums are three digits not two. These digits are the decimal representation of the single byte checksum.
Keith
Thanks to all of you. I've been working on a dealing machine file verify and translate utility. This discussion helped me add Duplimate for Windows *.DLM format to the library. The current version accepts two input files, verifies them to determine whether they represent the same board set, and when there is a third file and the board sets match reformats the inputs to create an output file in the specified format. Now, the supported formats are as follows:
*.ALL: DEAL305 format ( rw )
*.BRE: Autodealer format ( rw )
*.BRI: Duplimate format ( rw )
*.CSV: Comma Separated Values text format ( rw )
*.DGE: Duplimate format ( rw )
*.DLM: Duplimate for Windows format ( r )
*.DUP: Duplimate format ( rw )
*.HRF: Duplimate Hand Record Format ( rw )
*.HDM: Hand Dealer for Macintosh ( r )
*.PBN: Portable Bridge Notation format ( rw )
*.RBN: Richard's Bridge Notation format ( rw )
Any help with adding *.LIN, *.GIB, or other interesting formats would be appreciated.
The intended objective focuses on dealing machine operations. Given two files for the same event and session, the utility can verify them against one another---potentially helpful if there is some confusion about the correct file to use for dealing the boards. Also of occasional helpfulness, possessed of a dealing machine file in a format alien to one's dealing machine, this utility may provide a reformatted file for the same board set in a form acceptable to the dealing machine.
Thanks,
Brian Potter
e-mail: ClioBridgeGuy >at< att >dot< net
URL: Bridge at the Village
Bridge is more than just a card game. It is a cerebral sport. Bridge teaches you logic, reasoning, quick thinking, patience, concentration, and partnership skills.
- Martina Navratilova
#11
Posted 2019-November-17, 14:28
1 XOR 32 becomes 000001 XOR 100000 = 100001 i.e. 32
1 XOR 31 becomes 000001 XOR 011111 = 011110 i.e. 30
However if you play board 10 to 32
10 XOR 32 becomes 001010 XOR 100000 = 101010 i.e. 42
Actually, even this is only part of the story because 2 other factors, the dealing method and next board to be dealt are also included in the checksum.
If you're still interested I'd be very happy to send the .doc with all the details explained.
Brian