[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Bug-gnubg] Re: GnuBG: Fractional-ply evaluators
|
From: |
Ian Shaw |
|
Subject: |
RE: [Bug-gnubg] Re: GnuBG: Fractional-ply evaluators |
|
Date: |
Tue, 21 Oct 2003 08:51:01 +0100 |
On Tuesday, October 21, 2003 12:32 AM Nis Jorgensen wrote:
> I am very interested in this as well. It would be great to add 1.5-ply
> and 2-ply to the list. I think I asked Joseph to make his
> benchmark available some time ago, and I would like to repeat the
> request. If possible in some semi-readable format ...
>
Since Joseph is on holiday, and I have a significant chunk of his database, I'd
be happy to send what I have to you.
I've also worked out his position ID format (for Thomas Hauk) so that the
results are readable.
I'd be happy to send you what I have.
Copy of email follows. Spreadsheet is not attached because I don't want to post
it to the newsgroup. Email me privately if you want it.
> -----Original Message-----
> From: Thomas Hauk [mailto:address@hidden
> Sent: Wednesday, October 15, 2003 10:59 PM
> To: Ian Shaw
> Subject: BG move encoding
>
>
> How does that move encoding work? I see that the moves are listed as
> something like NOPJANAAAALGGNAAICDB, which is a 20-byte
> string. If I had
> to guess I would say that it's an expanded version of a 10-byte
> representation of a move... or something...
>
Joseph wrote,
"The positions are encoded as 20 character in the range of `A' to `F'. Each
letter stands for 4 bits (A == 0x0, F == 0xf), and concatenated they form the
80 bit GNUbg position ID."
As you pointed out, this is clearly not the case, since it contains letters
above "F", up to "P".
Now, "P" is the 16th letter.
Therefore, let's assume that each letter represents four bytes of hex code (A-P
instead of the more usual 0-9A-F), run through the conversion procedure in the
link you gave http://www.cs.arizona.edu/~gary/backgammon/positionid.html.
Sagnubg ID: NOPJANAAAALGGNAAICDB
Binary String:
11011110111110010000110100000000000000001011011001101101000000001000001000110001
6 byte binary groups encoded as decimal: 55 47 36 13 0 0 2 54 27 16 2 2
12 16 3
Gnubg ID (Base64 conversion): 3vkNAAC2bQCCMQ
Paste it in to gnubg, and voilà:
GNU Backgammon Position ID: 3vkNAAC2bQCCMQ
Match ID : cAkOAAAAAAAA
+24-23-22-21-20-19------18-17-16-15-14-13-+ O: Leader
| X O O X O O | | X | 0 points
| X O O X O O | | |
| O O O | | |
| O O | | |
| 6 | | |
| |BAR| |v (Cube: 1)
| | | |
| | | |
| | | |
| X X X X X | | | Rolled 43
| X X X X X | | | 0 points
+-1--2--3--4--5--6-------7--8--9-10-11-12-+ X: Trailer
Looks good to me!
In the attached spreadsheet, the first row is the position above, and the next
rows are the positions from the start of results-file022
m AGAAAAPEGOFLIAAAAAAA 3 4 OPGOIDAAAAAGAAAAAEAA -0.874862 OPGNADABAAAGAAAAAEAA
0.0346732 OPLGBFAAAAAGAAAAAEAA 0.0946298 NPFLADAIAAAGAAAAAEAA 0.243519
NPNNACAIAAAGAAAAAEAA 0.251542
I've verified that the played positions are legal moves from the start
position, but note that it inverts the board when pasted into gnubg. So, the
start position appears at the bottom of the screen. When you paste in the
position after the move, the player who has just moved is at the top.
I suppose this makes a certain sense, the player on roll is always at the
bottom. You'll just have to be aware of this when checking the equity. It
wouldn't be good to select the lowest equity because you were looking at it
from the opponent's point of view!
However, the equities don't agree with gnubg's output :(
GNU Backgammon Position ID: BgAA9G5bgAAAAA
Match ID : MAGuAAAAAAAA
+-1--2--3--4--5--6-------7--8--9-10-11-12-+ O: Leader
| O O O O O O | | | 0 points
| O O O O O | | | Rolled 43
| O O | | |
| O | | |
| | | |
| |BAR| |^ 5 point match (Cube: 1)
XX | | | |
XX | | | |
XX | | | |
XXX | X | | |
XXX | X | X | O | 0 points
+24-23-22-21-20-19------18-17-16-15-14-13-+ X: Trailer
1. Cubeful 0-ply 14/10 6/3 Eq.: -1.000
0.073 0.000 0.000 - 0.927 0.033 0.002
0-ply cubeful [expert]
2. Cubeful 0-ply 14/11 6/2 Eq.: -1.000 ( +0.000)
0.064 0.000 0.000 - 0.936 0.029 0.002
0-ply cubeful [expert]
3. Cubeful 0-ply 14/7 Eq.: -1.036 ( -0.036)
0.082 0.000 0.000 - 0.918 0.098 0.011
0-ply cubeful [expert]
4. Cubeful 0-ply 6/2 4/1 Eq.: -1.163 ( -0.163)
0.035 0.000 0.000 - 0.965 0.186 0.012
0-ply cubeful [expert]
5. Cubeful 0-ply 6/3 5/1 Eq.: -1.167 ( -0.167)
0.038 0.000 0.000 - 0.962 0.193 0.013
0-ply cubeful [expert]
1. Cubeful 0-ply 14/10 6/3 MWC: +0.4200
0.073 0.000 0.000 - 0.927 0.033 0.002
0-ply cubeful [expert]
2. Cubeful 0-ply 14/11 6/2 MWC: +0.4200 (+0.0000)
0.064 0.000 0.000 - 0.936 0.029 0.002
0-ply cubeful [expert]
3. Cubeful 0-ply 14/7 MWC: +0.4171 (-0.0029)
0.082 0.000 0.000 - 0.918 0.098 0.011
0-ply cubeful [expert]
4. Cubeful 0-ply 6/2 4/1 MWC: +0.4070 (-0.0130)
0.035 0.000 0.000 - 0.965 0.186 0.012
0-ply cubeful [expert]
5. Cubeful 0-ply 6/3 5/1 MWC: +0.4067 (-0.0133)
0.038 0.000 0.000 - 0.962 0.193 0.013
0-ply cubeful [expert]
I've tried equity & MWC, but I can't get the numbers to agree.
However, I've tried two examples of positions and follow up moves, and I'm
pretty sure the postion conversion is correct. All my examples are valid
positions and legal moves. Note also that the race 12 example only has 2 legal
moves, corresponding to Joseph's input file.
Furthermore, I tried converting to little endian format (using 2 1 4 3 6 5...
in the top row), and always get illegal positions.
Hope this helps. Perhaps Øystein has some idea about the equity format, since
he made the windows version of sagnubg.
-- Ian