crafty 21.6: mobility bug

Discussion of chess software programming and technical issues.

Moderator: Ras

User avatar
Roman Hartmann
Posts: 295
Joined: Wed Mar 08, 2006 8:29 pm

crafty 21.6: mobility bug

Post by Roman Hartmann »

There seems to be a mobility bug in crafty 21.6. One of the WAC-problems crafty 21.6 has problems with is WAC 120. It does find the proper move g6 at shallow depths but then it will switch to Rhg1 and stick with it.

But if I mirror WAC 120 crafty 21.6 does find g3 and also sticks with it. After outcommenting the for loop in evaluate.c for the rook mobility the behaviour vanished. After having a look a the mobility values in data.c I think only the first value in mobility_mask_r is a valid one. I changed the other values just to see if my assumption is right. 0x8484848484848484ULL,0x9090909090909090ULL, 0xC0C0C0C0C0C0C0C0ULL are the new values I used and then the behaviour is identical meaning that black and white want to put the rook on the open file and give the same scores. Just to make crafty play g3 and g6 i also decremented the last value in mobility_score_r to give mobility less weight.

I don't think that this asymmetry is wanted in crafty and it looks like a bug to me.

best regards
Roman

Edit: The comment regarding outcommenting parts of mobility code was only meant to explain how I found the bug. The code at this place is ok.

output of crafty 21.6 (without any code modifications):

Code: Select all

White(1): setboard r4rk1/1bn2qnp/3p1B1Q/p2P1pP1/1pp5/5N1P/PPB2P2/2KR3R w - -
White(1): analyze
...
                9     1.07   3.64   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Rf7
                                    4. Rhg1+ Kh8 5. Nd4 Rg8 6. Rxg8+ Kxg8
                                    7. Rg1+ Kh8
                9->   1.21   3.64   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Rf7
                                    4. Rhg1+ Kh8 5. Nd4 Rg8 6. Rxg8+ Kxg8
                                    7. Rg1+ Kh8
               10     1.32   3.68   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Rf7
                                    4. Rhg1+ Kh8 5. Nd4 Rg8 6. Rxg8+ Kxg8
                                    7. Rg1+ Kh8 8. Bf4 Bxd5 9. Bxd6
               10->   1.55   3.68   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Rf7
                                    4. Rhg1+ Kh8 5. Nd4 Rg8 6. Rxg8+ Kxg8
                                    7. Rg1+ Kh8 8. Bf4 Bxd5 9. Bxd6
               11     1.92   3.68   1. g6 Qxg6 2. Bxg7 Rf7 3. Rhg1 Qxh6+
                                    4. Bxh6+ Kh8 5. Nd4 Rg8 6. Rxg8+ Kxg8
                                    7. Rg1+ <HT>
               11     5.41   3.89   1. Rhg1 Qg6 2. Nh4 Rxf6 3. Nxg6 Rxg6
                                    4. Qh4 Bxd5 5. Rge1 b3 6. axb3 cxb3
               11->   5.49   3.89   1. Rhg1 Qg6 2. Nh4 Rxf6 3. Nxg6 Rxg6
                                    4. Qh4 Bxd5 5. Rge1 b3 6. axb3 cxb3
...
               16->   3:24   4.58   1. Rhg1 Qg6 2. Nh4 Qxh6 3. gxh6 Rxf6
                                    4. Rxg7+ Kh8 5. Rxc7 Ba6 6. Nxf5 Bc8
                                    7. Ne3 Rxh6 8. Nxc4 Bxh3 9. Re1
               17     4:34   4.69   1. Rhg1 Qg6 2. Nh4 Qxh6 3. gxh6 Rxf6
                                    4. Rxg7+ Kh8 5. Rxc7 Ba6 6. Nxf5 b3
                                    7. axb3 cxb3 8. Be4 Bc8 9. Nd4 Rxh6
           

White(1): setboard 2kr3r/ppb2p2/5n1p/1PP5/P2p1Pp1/3P1b1q/1BN2QNP/R4RK1 b - -
Black(1): analyze

               14->  15.67  -4.50   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. Nxd4 Rhe8
                                    7. f5 Be5 8. Re1 Bxd4 9. Rxe8 Bxb2
               15    23.57  -4.64   1. ... g3 2. Qxg3 Bxg2 3. Rf2 Rhg8   
                                    4. Rxg2 Rxg3 5. Rxg3 Rg8 6. Rxg8+ Nxg8
                                    7. Rf1 Qxd3 8. Nxd4 Qc4 9. Re1 Qxc5
               15->  32.73  -4.64   1. ... g3 2. Qxg3 Bxg2 3. Rf2 Rhg8   
                                    4. Rxg2 Rxg3 5. Rxg3 Rg8 6. Rxg8+ Nxg8
                                    7. Rf1 Qxd3 8. Nxd4 Qc4 9. Re1 Qxc5
               16    48.08  -4.68   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. Nxd4 Rhe8
                                    7. Nf5 Rxd3 8. Nxh6 Re2 9. Be5 Bxe5
                                    10. fxe5 Rxe5 11. Rxf7 Rxc5
               16->   1:12  -4.68   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. Nxd4 Rhe8
                                    7. Nf5 Rxd3 8. Nxh6 Re2 9. Be5 Bxe5
                                    10. fxe5 Rxe5 11. Rxf7 Rxc5
               17     1:46  -4.85   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. Nxd4 Rhe8
                                    7. f5 Be5 8. Ne6 Bxb2 9. Nxd8 Kxd8
                                    10. Kg2
               17     2:45   7/41?  1. ... Nd5     (983Knps)
after the code modifications and recompiling (note that also the values are now symmetrical for black and white):

Code: Select all

white:
               15    25.57   4.64   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Kh8
                                    4. Bxf8 Rxf8 5. Rhe1 Nxd5 6. Nh4 f4
                                    7. Be4 Re8 8. Nf5 Re6 9. Bxd5 Bxd5
                                    10. Rxe6 Bxe6 11. Nxd6 Bxh3 12. Nxc4
               15->  35.98   4.64   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Kh8
                                    4. Bxf8 Rxf8 5. Rhe1 Nxd5 6. Nh4 f4
                                    7. Be4 Re8 8. Nf5 Re6 9. Bxd5 Bxd5
                                    10. Rxe6 Bxe6 11. Nxd6 Bxh3 12. Nxc4
               16    51.18   4.80   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Kh8
                                    4. Bxf8 Rxf8 5. Rhe1 Bxd5 6. Nh4 c3
                                    7. Re7 Rf7 8. Rxc7 Rxc7 9. Rxd5 cxb2+
                                    10. Kxb2
               16->   1:16   4.80   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Kh8
                                    4. Bxf8 Rxf8 5. Rhe1 Bxd5 6. Nh4 c3
                                    7. Re7 Rf7 8. Rxc7 Rxc7 9. Rxd5 cxb2+
                                    10. Kxb2
               17     1:48   4.80   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Kh8
                                    4. Bxf8 Rxf8 5. Rhe1 Bxd5 6. Nh4 c3
                                    7. Re7 Rf7 8. Rxc7 Rxc7 9. Rxd5 cxb2+
                                    10. Kxb2
          
....
black:
               15    22.25  -4.64   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. f5 Rhe8
                                    7. Nxd4 Be5 8. Re1 Nf4 9. Re3 Bxd4
                                    10. Bxd4 Rxe3 11. Bxe3 Nxd3 12. Bxh6
                                    Nxc5
               15->  30.97  -4.64   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. f5 Rhe8
                                    7. Nxd4 Be5 8. Re1 Nf4 9. Re3 Bxd4
                                    10. Bxd4 Rxe3 11. Bxe3 Nxd3 12. Bxh6
                                    Nxc5
               16    49.34  -4.82   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. f5 Rhe8
                                    7. Nxd4 Be5 8. Re1 Nf6 9. b6 axb6
               16->   1:09  -4.82   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. f5 Rhe8
                                    7. Nxd4 Be5 8. Re1 Nf6 9. b6 axb6
               17     1:42  -4.80   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. Bxd4 Rhe8
                                    7. c6 Re2 8. Rf2 Rxc2 9. Rxc2 Rxd4
                                    10. cxb7+ Kxb7
Top
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: crafty 21.6: mobility bug

Post by bob »

Roman Hartmann wrote:There seems to be a mobility bug in crafty 21.6. One of the WAC-problems crafty 21.6 has problems with is WAC 120. It does find the proper move g6 at shallow depths but then it will switch to Rhg1 and stick with it.

But if I mirror WAC 120 crafty 21.6 does find g3 and also sticks with it. After outcommenting the for loop in evaluate.c for the rook mobility the behaviour vanished. After having a look a the mobility values in data.c I think only the first value in mobility_mask_r is a valid one. I changed the other values just to see if my assumption is right. 0x8484848484848484ULL,0x9090909090909090ULL, 0xC0C0C0C0C0C0C0C0ULL are the new values I used and then the behaviour is identical meaning that black and white want to put the rook on the open file and give the same scores. Just to make crafty play g3 and g6 i also decremented the last value in mobility_score_r to give mobility less weight.

I don't think that this asymmetry is wanted in crafty and it looks like a bug to me.

best regards
Roman

Edit: The comment regarding outcommenting parts of mobility code was only meant to explain how I found the bug. The code at this place is ok.

output of crafty 21.6 (without any code modifications):

Code: Select all

White(1): setboard r4rk1/1bn2qnp/3p1B1Q/p2P1pP1/1pp5/5N1P/PPB2P2/2KR3R w - -
White(1): analyze
...
                9     1.07   3.64   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Rf7
                                    4. Rhg1+ Kh8 5. Nd4 Rg8 6. Rxg8+ Kxg8
                                    7. Rg1+ Kh8
                9->   1.21   3.64   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Rf7
                                    4. Rhg1+ Kh8 5. Nd4 Rg8 6. Rxg8+ Kxg8
                                    7. Rg1+ Kh8
               10     1.32   3.68   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Rf7
                                    4. Rhg1+ Kh8 5. Nd4 Rg8 6. Rxg8+ Kxg8
                                    7. Rg1+ Kh8 8. Bf4 Bxd5 9. Bxd6
               10->   1.55   3.68   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Rf7
                                    4. Rhg1+ Kh8 5. Nd4 Rg8 6. Rxg8+ Kxg8
                                    7. Rg1+ Kh8 8. Bf4 Bxd5 9. Bxd6
               11     1.92   3.68   1. g6 Qxg6 2. Bxg7 Rf7 3. Rhg1 Qxh6+
                                    4. Bxh6+ Kh8 5. Nd4 Rg8 6. Rxg8+ Kxg8
                                    7. Rg1+ <HT>
               11     5.41   3.89   1. Rhg1 Qg6 2. Nh4 Rxf6 3. Nxg6 Rxg6
                                    4. Qh4 Bxd5 5. Rge1 b3 6. axb3 cxb3
               11->   5.49   3.89   1. Rhg1 Qg6 2. Nh4 Rxf6 3. Nxg6 Rxg6
                                    4. Qh4 Bxd5 5. Rge1 b3 6. axb3 cxb3
...
               16->   3:24   4.58   1. Rhg1 Qg6 2. Nh4 Qxh6 3. gxh6 Rxf6
                                    4. Rxg7+ Kh8 5. Rxc7 Ba6 6. Nxf5 Bc8
                                    7. Ne3 Rxh6 8. Nxc4 Bxh3 9. Re1
               17     4:34   4.69   1. Rhg1 Qg6 2. Nh4 Qxh6 3. gxh6 Rxf6
                                    4. Rxg7+ Kh8 5. Rxc7 Ba6 6. Nxf5 b3
                                    7. axb3 cxb3 8. Be4 Bc8 9. Nd4 Rxh6
           

White(1): setboard 2kr3r/ppb2p2/5n1p/1PP5/P2p1Pp1/3P1b1q/1BN2QNP/R4RK1 b - -
Black(1): analyze

               14->  15.67  -4.50   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. Nxd4 Rhe8
                                    7. f5 Be5 8. Re1 Bxd4 9. Rxe8 Bxb2
               15    23.57  -4.64   1. ... g3 2. Qxg3 Bxg2 3. Rf2 Rhg8   
                                    4. Rxg2 Rxg3 5. Rxg3 Rg8 6. Rxg8+ Nxg8
                                    7. Rf1 Qxd3 8. Nxd4 Qc4 9. Re1 Qxc5
               15->  32.73  -4.64   1. ... g3 2. Qxg3 Bxg2 3. Rf2 Rhg8   
                                    4. Rxg2 Rxg3 5. Rxg3 Rg8 6. Rxg8+ Nxg8
                                    7. Rf1 Qxd3 8. Nxd4 Qc4 9. Re1 Qxc5
               16    48.08  -4.68   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. Nxd4 Rhe8
                                    7. Nf5 Rxd3 8. Nxh6 Re2 9. Be5 Bxe5
                                    10. fxe5 Rxe5 11. Rxf7 Rxc5
               16->   1:12  -4.68   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. Nxd4 Rhe8
                                    7. Nf5 Rxd3 8. Nxh6 Re2 9. Be5 Bxe5
                                    10. fxe5 Rxe5 11. Rxf7 Rxc5
               17     1:46  -4.85   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. Nxd4 Rhe8
                                    7. f5 Be5 8. Ne6 Bxb2 9. Nxd8 Kxd8
                                    10. Kg2
               17     2:45   7/41?  1. ... Nd5     (983Knps)
after the code modifications and recompiling (note that also the values are now symmetrical for black and white):

Code: Select all

white:
               15    25.57   4.64   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Kh8
                                    4. Bxf8 Rxf8 5. Rhe1 Nxd5 6. Nh4 f4
                                    7. Be4 Re8 8. Nf5 Re6 9. Bxd5 Bxd5
                                    10. Rxe6 Bxe6 11. Nxd6 Bxh3 12. Nxc4
               15->  35.98   4.64   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Kh8
                                    4. Bxf8 Rxf8 5. Rhe1 Nxd5 6. Nh4 f4
                                    7. Be4 Re8 8. Nf5 Re6 9. Bxd5 Bxd5
                                    10. Rxe6 Bxe6 11. Nxd6 Bxh3 12. Nxc4
               16    51.18   4.80   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Kh8
                                    4. Bxf8 Rxf8 5. Rhe1 Bxd5 6. Nh4 c3
                                    7. Re7 Rf7 8. Rxc7 Rxc7 9. Rxd5 cxb2+
                                    10. Kxb2
               16->   1:16   4.80   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Kh8
                                    4. Bxf8 Rxf8 5. Rhe1 Bxd5 6. Nh4 c3
                                    7. Re7 Rf7 8. Rxc7 Rxc7 9. Rxd5 cxb2+
                                    10. Kxb2
               17     1:48   4.80   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Kh8
                                    4. Bxf8 Rxf8 5. Rhe1 Bxd5 6. Nh4 c3
                                    7. Re7 Rf7 8. Rxc7 Rxc7 9. Rxd5 cxb2+
                                    10. Kxb2
          
....
black:
               15    22.25  -4.64   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. f5 Rhe8
                                    7. Nxd4 Be5 8. Re1 Nf4 9. Re3 Bxd4
                                    10. Bxd4 Rxe3 11. Bxe3 Nxd3 12. Bxh6
                                    Nxc5
               15->  30.97  -4.64   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. f5 Rhe8
                                    7. Nxd4 Be5 8. Re1 Nf4 9. Re3 Bxd4
                                    10. Bxd4 Rxe3 11. Bxe3 Nxd3 12. Bxh6
                                    Nxc5
               16    49.34  -4.82   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. f5 Rhe8
                                    7. Nxd4 Be5 8. Re1 Nf6 9. b6 axb6
               16->   1:09  -4.82   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. f5 Rhe8
                                    7. Nxd4 Be5 8. Re1 Nf6 9. b6 axb6
               17     1:42  -4.80   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. Bxd4 Rhe8
                                    7. c6 Re2 8. Rf2 Rxc2 9. Rxc2 Rxd4
                                    10. cxb7+ Kxb7
Thanks... I will look at it. That was certainly written at the last minute to replace the older way we had mobility written while testing...

OK, something is wrong with the values you are using as well. The 4 masks are supposed to have the following features:

(0) 1-bits on the a/h file. 81 does that, so a string of 8181818181818181 has 1 bits on every a-file square and every h-file square.

(1) 1 bits on the b-g file. 42 (01000010 binary) does this.

(2) 1 bits on the c-f file, 24 (00100100) does this.

(3) 1 bits on the d-e file (18 (00011000) does this.

I am not following your description of the problem at all in this context). I tried that position and did the following:

setup position
score
flip
score
flop
score
flip
score

and I got the same score (sign changes on flip only) which suggests no asymmetry. Can you be more specific in what you are seeing? I particularly do not understand the masks you say you are using as they say:

In crafty bit 0 (lsb) is a1, bit 1 is b1, ... bit 7 is h1, bit 8 is a2, etc...

0x8484848484848484ULL

binary 10000100 says c file and h file, which is not what it is supposed to do.

0x9090909090909090ULL

binary 10010000 says e file and h-file which also makes no sense at all.

0xC0C0C0C0C0C0C0C0UL

binary 11000000 says g-h files only which again makes no sense at all.

Another _much_ more important note is that your method of testing is not going to work for any program I know of, because when you flip the board, the order of move generation changes, and the shape of the tree changes. For programs that use hash tables, and search reductions, and such, the trees will cover different nodes, which can result in different scores in lots of positions. When I try your positions, and type "score" I get identical scores in all positions as I expected. When I search them I do get different scores. But it isn't because of any asymmetry in the rook mobility code. You can print the "mobility_mask_r" values out using "DisplayBitBoard()" in crafty and you will see that element 0 is that a/h files, element 1 is the b/g files, etc... which is how it is supposed to look.
Top
User avatar
Roman Hartmann
Posts: 295
Joined: Wed Mar 08, 2006 8:29 pm

Re: crafty 21.6: mobility bug

Post by Roman Hartmann »

Hi Bob,
you're right the static eval does return the same values for mobility for the flipped sides but it does not return the same values for the flipped position when analyzing and therefore picks different moves. Below is again WAC 120 analyzed with unmodified crafty 21.6.

While I certainly do agree that there is a difference by searching the flipped sides (hash, move ordering as you pointed already out) you will also note that crafty will pick g3 and g6 if you comment out the mobility part (just comment the for loop out). So you will have at least to agree that the mobility part _is_ responsible here for the change in evaluation and picking a different move.

Regarding the mask values I changed, I just realized that my calculator doesn't show the leading 0's, so my 3 given 64-bit masks are invalid as I read them from left to right. Thanks for your explanation regarding the masks and how to print them out.

unmodified crafty 21.6:
white:

Code: Select all

               14    22.58   4.58   1. Rhg1 Qg6 2. Nh4 Qxh6 3. gxh6 Rxf6
                                    4. Rxg7+ Kh8 5. Rxc7 Ba6 6. Nxf5 Bc8
                                    7. Ne3 Rxh6 8. Re1 Bxh3 9. Nxc4
               14->  30.49   4.58   1. Rhg1 Qg6 2. Nh4 Qxh6 3. gxh6 Rxf6
                                    4. Rxg7+ Kh8 5. Rxc7 Ba6 6. Nxf5 Bc8
                                    7. Ne3 Rxh6 8. Re1 Bxh3 9. Nxc4
               15    43.26   4.57   1. Rhg1 Qg6 2. Nh4 Qxh6 3. gxh6 Rxf6
                                    4. Rxg7+ Kh8 5. Rxc7 Ba6 6. Nxf5 Bc8
                                    7. Ne3 Rxh6 8. Re1 Ba6
after flipping the position:
black:

Code: Select all

               14    16.18  -4.50   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. Nxd4 Rhe8
                                    7. f5 Be5 8. Re1 Bxd4 9. Rxe8 Bxb2
               14->  22.10  -4.50   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Nh5 6. Nxd4 Rhe8
                                    7. f5 Be5 8. Re1 Bxd4 9. Rxe8 Bxb2
               15    34.21  -4.64   1. ... g3 2. Qxg3 Bxg2 3. Rf2 Rhg8   
                                    4. Rxg2 Rxg3 5. Rxg3 Rg8 6. Rxg8+ Nxg8
                                    7. Rf1 Qxd3 8. Nxd4 Qc4 9. Re1 Qxc5
the same two positions now with the mobility part commented out, otherwise I didn't touch the sources:
for both rook routines I commented the following part out:

Code: Select all

    /* for (i=0; i<4; i++) {
      tscore += PopCnt(moves & mobility_mask_r[i]) * mobility_score_r[i];
      } */
white:

Code: Select all

               14    15.83   4.45   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Kh8
                                    4. Bxf8 Rxf8 5. Rhe1 Nxd5 6. Nh4 Nf4
                                    7. Bxf5 Ng2 8. Nxg2 Rxf5
               14->  22.45   4.45   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Kh8
                                    4. Bxf8 Rxf8 5. Rhe1 Nxd5 6. Nh4 Nf4
                                    7. Bxf5 Ng2 8. Nxg2 Rxf5
               15    29.99   4.45   1. g6 Qxg6 2. Bxg7 Qxh6+ 3. Bxh6 Kh8
                                    4. Bxf8 Rxf8 5. Rhe1 Nxd5 6. Nh4 Nf4
                                    7. Bxf5 Ng2 8. Nxg2 Rxf5
after flipping the position
black:

Code: Select all

               14    18.00  -4.45   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Rhe8 6. Nxd4 Nh5
                                    7. Nf5 Bxf4 8. Ng7 Nxg7 9. Rxf4
               14->  24.23  -4.45   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Rhe8 6. Nxd4 Nh5
                                    7. Nf5 Bxf4 8. Ng7 Nxg7 9. Rxf4
               15    32.25  -4.45   1. ... g3 2. Qxg3 Bxg2 3. Qxh3+ Bxh3 
                                    4. Kh1 Bxf1 5. Rxf1 Rhe8 6. Nxd4 Nh5
                                    7. Nf5 Bxf4 8. Ng7 Nxg7 9. Rxf4
Now we get exactly the same scores even though the move ordering, hash moves are probably different. So mobility is obviously responsible for the change. I do get your point that there is a difference in the trees when searching flipped sides but I'm not yet convinced that mobility should behave like this.

best regards
Roman
Top
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: crafty 21.6: mobility bug

Post by bob »

I am not sure what to say here. If you take this code:


for (i=0; i<4; i++) {
tscore += PopCnt(moves & mobility_mask_r) * mobility_score_r;
}

What it does is to iterate 4 times. moves is the set of moves from the square in question, and that won't change whether you flip or mirror (right-to-left) the board. I and that with 4 masks, first the mask for the a/h files and add up the number of bits set and add in the mobility score for moving on the a/h files. I repeat for the b/g files, then the c/f files, and finally the d/e files. So perhaps I am doing something wrong in calculating "moves", which is a magic calculation but does factor out queens and rooks so that mobility passes thru them. I'll take a close look at that, as the bug might be prior to the loop above and since the above loop is the only thing that uses "moves" then commenting this out would hide the bug... back in a bit...
Top
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: crafty 21.6: mobility bug

Post by bob »

OK. I have been over that part of the code with a microscope. There is no asymmetry in that code whatsoever. I ran about 50,000 positions thru the evaluation test which flips/flops the board in both directions (horizontally and vertically) to verify that the evaluation is symmetric with color and edge of the board...

I can tell you that _many_ positions will show different evaluations when searched to the same depth in Crafty, because search reductions are a bit ad-hoc in how they are applied since the hash table gets written to in a different order due to the order moves are searched when colors are swapped.

I never test like that for this very reason. It can take several times as long to search a position after it is flipped or flopped, or it can take a fraction of the time. It is just the luck of the move ordering...
Top
jwes
Posts: 778
Joined: Sat Jul 01, 2006 7:11 am

Re: crafty 21.6: mobility bug

Post by jwes »

It seems to be related to hashing. If i set hash to 48k, I get g6/g3 as the best move with the same value for both.
Top
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: crafty 21.6: mobility bug

Post by bob »

jwes wrote:It seems to be related to hashing. If i set hash to 48k, I get g6/g3 as the best move with the same value for both.
That was my original guess. Hashing changes results when the order of the moves is changed, and flip/flopping the board around definitely changes move generation order.
Top
User avatar
Roman Hartmann
Posts: 295
Joined: Wed Mar 08, 2006 8:29 pm

Re: crafty 21.6: mobility bug

Post by Roman Hartmann »

bob wrote:OK. I have been over that part of the code with a microscope. There is no asymmetry in that code whatsoever. I ran about 50,000 positions thru the evaluation test which flips/flops the board in both directions (horizontally and vertically) to verify that the evaluation is symmetric with color and edge of the board...

I can tell you that _many_ positions will show different evaluations when searched to the same depth in Crafty, because search reductions are a bit ad-hoc in how they are applied since the hash table gets written to in a different order due to the order moves are searched when colors are swapped.

I never test like that for this very reason. It can take several times as long to search a position after it is flipped or flopped, or it can take a fraction of the time. It is just the luck of the move ordering...
Sorry for wasting your time. Seems my new testing sheme shouldn't be applied 1:1 to other engines. I was aware that hashing might have an influence on the search though but after commenting the mobility part out I thought I found a bug as the behaviour changed ...

Roman
Top

Return to “Computer Chess Club: Programming and Technical Discussions”