Winboard Forum

by **Uri Blass** » 14 Sep 2006, 08:00

I am in the process of implementing FRC move generator
and I cannot find perft numbers to check if I have no bugs.

Are there perft result of different positions when castling is allowed and the king and rooks are not in the same squares as normal chess?

Uri

by **Uri Blass** » 14 Sep 2006, 08:41

At this time I still have bugs in perft
one of my mistakes was that I assumed that all the squares between the rook and the destination square must be empty like normal chess and it is not the case and here castling is legal.

nr1kqrbn/pbpppppp/1p6/8/8/1P6/PBPPPPPP/NR1KQRBN w KQkq - - 0 1

I understand that the king square can be in the rook path and the rook square can be in the king path but not more pieces than it.

Note that I check after every change that I did not break the opening position analysis in normal chess.

I still see that I have some bugs because movei crash when I give it to analyze this fen.

perft1 is correct
26 so knowing perft of bigger numbers may help
perft2=676 is also correct
Correction:no it is not 676

It was 670 and I assumed wrong that it needs to be 26*26 and did not read the output correctly and thought the computer printed 676

You should also check it

setboard nr1kqrbn/pbpppppp/1p6/8/8/1P6/PBPPPPPP/NR1KQRBN w KQkq - - 0 1
perft 2
a2a3 26
a2a4 26
c2c3 26
c2c4 26
d2d3 26
d2d4 26
e2e3 26
e2e4 24
f2f3 25
f2f4 26
g2g3 27
g2g4 27
h2h3 26
h2h4 26
b3b4 26
h1g3 26
b2a3 26
b2c1 26
b2c3 26
b2d4 26
b2e5 25
b2f6 24
b2g7 24
b1c1 26
d1c1 26
d1c1 26
perft(2) = 670,time=562

I get the following

setboard nr1kqrbn/pbpppppp/1p6/8/8/1P6/PBPPPPPP/NR1KQRBN w KQkq - - 0 1
perft 3
a2a3 618
a2a4 644
c2c3 566
c2c4 697
d2d3 775
d2d4 671
e2e3 673
e2e4 672
f2f3 874
f2f4 933
g2g3 643
g2g4 670
h2h3 670
h2h4 670
b3b4 697
h1g3 698
b2a3 618
b2c1 489
b2c3 644
b2d4 696
b2e5 722
b2f6 652
b2g7 660
b1c1 592
d1c1 594
d1c1 670
perft(3) = 17508

setboard nr1kqrbn/pbpppppp/1p6/8/8/1P6/PBPPPPPP/NR1KQRBN w KQkq - - 0 1
perft 4
a2a3 16136
a2a4 16775
c2c3 14890
c2c4 18085
d2d3 20842
d2d4 18950
e2e3 17564
e2e4 16537
f2f3 22025
f2f4 24270
g2g3 17131
g2g4 17854
h2h3 17461
h2h4 17436
b3b4 18242
h1g3 18057
b2a3 14940
b2c1 12162
b2c3 16092
b2d4 17460
b2e5 17099
b2f6 14408
b2g7 16026
b1c1 15404
d1c1 14724
d1c1 15409
perft(4) = 445979,time=578

setboard nr1kqrbn/pbpppppp/1p6/8/8/1P6/PBPPPPPP/NR1KQRBN w KQkq - - 0 1
perft 5
a2a3 387570
a2a4 416024
c2c3 334381
c2c4 487786
d2d3 653005
d2d4 546476
e2e3 452648
e2e4 470254
f2f3 751792
f2f4 844933
g2g3 403816
g2g4 443638
h2h3 449855
h2h4 447392
b3b4 478933
h1g3 483834
b2a3 353610
b2c1 247828
b2c3 393615
b2d4 450141
b2e5 468289
b2f6 391635
b2g7 421483
b1c1 360402
d1c1 330094
d1c1 405232
perft(5) = 11874666

setboard nr1kqrbn/pbpppppp/1p6/8/8/1P6/PBPPPPPP/NR1KQRBN w KQkq - - 0 1
perft 6
a2a3 10264700
a2a4 11143824
c2c3 8940502
c2c4 12885436
d2d3 17222718
d2d4 14463030
e2e3 12019959
e2e4 12057048
f2f3 19856096
f2f4 22601485
g2g3 10932409
g2g4 12053211
h2h3 12025636
h2h4 11954835
b3b4 12924456
h1g3 12828164
b2a3 9247551
b2c1 6762066
b2c3 10496293
b2d4 12114669
b2e5 12486333
b2f6 9233031
b2g7 10376620
b1c1 9645812
d1c1 8874311
d1c1 9633110
perft(6) = 313043305,time=4563

The thing crash at perft 7 and give the following output before crashing

setboard nr1kqrbn/pbpppppp/1p6/8/8/1P6/PBPPPPPP/NR1KQRBN w KQkq - - 0 1
perft 7
a2a3 258035648
a2a4 285731257
c2c3 212471156
c2c4 357420319
d2d3 554658693
d2d4 437264514
e2e3 317675987
e2e4 359658919
f2f3 671989675
f2f4 772981302
g2g3 267424728
g2g4 312902176
h2h3 322584161
h2h4 316662107
b3b4 348249224
h1g3 353854155

Uri

by **Tony van Roon-Werten** » 14 Sep 2006, 09:34

Nasty position.

Did you take into account that the rooks on the b file can be pinned ?

The king goes from d1 to c1, d1 attacked ? No, c1 attacked ? No, so castling must be allowed, and only after the rook moves, the king on c1 is attacked.

If your engine (like mine) crashes on a king capture, it would explain your problem.

Tony

by **Uri Blass** » 14 Sep 2006, 09:39

Tony van Roon-Werten wrote:Nasty position.

Did you take into account that the rooks on the b file can be pinned ?

The king goes from d1 to c1, d1 attacked ? No, c1 attacked ? No, so castling must be allowed, and only after the rook moves, the king on c1 is attacked.

If your engine (like mine) crashes on a king capture, it would explain your problem.

Tony

I did not consider pins in castling but I do not see how pins can be relevant in 7 ply search of perft when in the last move I only generate moves.

I see no way for the black rook or the black queen to get into
square like A1 so fast so it seems that the reason movei crash is different here.

It may crash after king capture because I generate only legal moves so I assume no king capture in the search.

Uri

by **Tony van Roon-Werten** » 14 Sep 2006, 10:42

Uri Blass wrote:
Tony van Roon-Werten wrote:Nasty position.

Did you take into account that the rooks on the b file can be pinned ?

The king goes from d1 to c1, d1 attacked ? No, c1 attacked ? No, so castling must be allowed, and only after the rook moves, the king on c1 is attacked.

If your engine (like mine) crashes on a king capture, it would explain your problem.

Tony

I did not consider pins in castling but I do not see how pins can be relevant in 7 ply search of perft when in the last move I only generate moves.

I see no way for the black rook or the black queen to get into
square like A1 so fast so it seems that the reason movei crash is different here.

It may crash after king capture because I generate only legal moves so I assume no king capture in the search.

Uri

Seems correct. One would need 8 ply (or you 9 ply) to reach that problem.

Another problem that might arise here is when castling short, the rook might cature itself.

Rook and king capturing own pieces seem to be a standard problem in FRC implementations.

It can happen on ply 7 here, but I'm not sure if the problem would only arise from ply 8 for you.

Tony

by **Uri Blass** » 14 Sep 2006, 10:59

Tony van Roon-Werten wrote:
Uri Blass wrote:
Tony van Roon-Werten wrote:Nasty position.

Did you take into account that the rooks on the b file can be pinned ?

The king goes from d1 to c1, d1 attacked ? No, c1 attacked ? No, so castling must be allowed, and only after the rook moves, the king on c1 is attacked.

If your engine (like mine) crashes on a king capture, it would explain your problem.

Tony

I did not consider pins in castling but I do not see how pins can be relevant in 7 ply search of perft when in the last move I only generate moves.

I see no way for the black rook or the black queen to get into
square like A1 so fast so it seems that the reason movei crash is different here.

It may crash after king capture because I generate only legal moves so I assume no king capture in the search.

Uri

Seems correct. One would need 8 ply (or you 9 ply) to reach that problem.

Another problem that might arise here is when castling short, the rook might cature itself.

Rook and king capturing own pieces seem to be a standard problem in FRC implementations.

It can happen on ply 7 here, but I'm not sure if the problem would only arise from ply 8 for you.

Tony

It is certainly not the problem here

Movei also crash in perft 6 in the following fen:
nr1kqrbn/pbpppppp/1p6/8/8/BP6/P1PPPPPP/NR1KQRBN b KQkq - - 0 1

Uri

by **Uri Blass** » 14 Sep 2006, 12:04

This is not the problem here but when I investigate my code I find
that I have a basic mistake here.

I assume in my make move that in short castling the king goes to the right side of the board when the king goes to the left side of the board in long castling.

It is simply not correct because the king can do no move or even in case Ra1 Kb1 Rc1 to go right to C1

Programming chess960 is not a simple problem and assumptions
that are obvious in normal chess simple stop to be correct in chess960

Maybe one of the reasons that it was easy for tord is the fact that he simply did not care about optimization of the algorithm so he could do slow castling.

It is correct that speed of making castling moves is not very important because they do not happen often but I prefer to use faster algorithm for making castling moves and not to use slower algorithm.

I will check it but I suspect that something wrong happens to my piece list when I make castle moves when tord simply initialize the piece list by slow initialization.

I found that white queen got into e8 during the 6 ply perft when I do not know how it got there.

Uri

by **Volker Annuss** » 14 Sep 2006, 12:48

Hello Uri,

here is an old perft-thread for FRC with some test positions and a description how to use perft in my engine Hermann: http://www.vpittlik.org/wbforum/viewtopic.php?t=1404

To get the faster results from Hermann you can type

Code: Select all: perft depth <d> Hash <size in MB>

My perft is not optimized. It does things like generating thretened squares that would not be necessary for perft, so take a little time.

Greetings
Volker

by **Uri Blass** » 14 Sep 2006, 13:45

Volker Annuss wrote:Hello Uri,

here is an old perft-thread for FRC with some test positions and a description how to use perft in my engine Hermann: http://www.vpittlik.org/wbforum/viewtopic.php?t=1404

To get the faster results from Hermann you can type
Code: Select all
perft depth <d> Hash <size in MB>

My perft is not optimized. It does things like generating thretened squares that would not be necessary for perft, so take a little time.

Greetings
Volker

Thanks

I will look at it later.

It seems to me that I have many bugs to solve:

bug 1:capturing my own pieces
my make move assumes that the move is capture if the to is not an empty square
It is correct in normal chess but not in chess960

The result is that I reduce the number of pieces of the type of the to square by 1 when it is not correct.

bug 2:pins
I assume that if the opponent does not threat the path between from and to castling is legal when it is not correct when simple
example is white king d1 rook b1 black queen a1.

the black queen does not control c1 or d1 but it does not make castling legal.

bug 3:something different
bug 1 and bug 2 do not explain the bug that I have in the position that I posted

I already corrected bug 4 that is assuming that castling are for different directions

Uri

by **Reinhard Scharnagl** » 14 Sep 2006, 19:19

Here are some numbers from SMIRF (hopefully correct ;-) ):

Code: Select all: FEN: nr1kqrbn/pbpppppp/1p6/8/8/1P6/PBPPPPPP/NR1KQRBN w KQkq - 0 1 +-a--*--c--*--e--*--g--h-+ MS Vis.Studio C++ 32-Bit-Vers. 13.10 8 |[n][r] [k][q][r][b][n]| (Compilation: Sep 14 2006) 7 |[p][b][p][p][p][p][p][p]| 6 | [p] ::: ::: :::| Perft Testseries 5 |::: ::: ::: ::: | (with TT caching +1024. MB / 4-fold) 4 | ::: ::: ::: :::| TT Access Success +59.0% 3 |:::::: ::: ::: | 2 || Smirf Test No.: 0 1 |<N><R>:::<K><Q><R><N>| =>+-a--*--c--*--e--*--g--h-+ Break Time: +5.000 Sec. Ply Nodes all (x) (ep) all (+) (#) Prom. Cstl. Sec. ------------------------------------------------------------------------------- 1 26 1 0 0 0 0 1 0 2 670 28 0 1 0 0 26 0 3 17458 814 0 93 0 0 565 0 4 449368 22814 0 2878 0 0 14629 0.016 5 12050739 681668 290 111040 11 0 324894 0.265 6 319767919 19645925 6938 3193732 589 0 8646625 3.562 7 8961813899 606224482 513431 111563740 82528 0 201867319 45.84 ------------------------------------------------------------------------------- FEN: nr1kqrbn/pbpppppp/1p6/8/8/BP6/P1PPPPPP/NR1KQRBN b KQkq - 0 1 =>+-a--*--c--*--e--*--g--h-+ MS Vis.Studio C++ 32-Bit-Vers. 13.10 8 |[n][r] [k][q][r][b][n]| (Compilation: Sep 14 2006) 7 |[p][b][p][p][p][p][p][p]| 6 | [p] ::: ::: :::| Perft Testseries 5 |::: ::: ::: ::: | (with TT caching +1024. MB / 4-fold) 4 | ::: ::: ::: :::| TT Access Success +58.0% 3 |::: ::: ::: | 2 |:::| Smirf Test No.: 1 1 |<N><R>:::<K><Q><R><N>| +-a--*--c--*--e--*--g--h-+ Break Time: +5.000 Sec. Ply Nodes all (x) (ep) all (+) (#) Prom. Cstl. Sec. ------------------------------------------------------------------------------- 1 26 1 0 0 0 0 1 0 2 618 28 0 22 0 0 26 0 3 15681 798 0 84 0 0 502 0 4 382020 20232 0 10744 0 0 12187 0.015 5 10110878 613999 246 94667 12 0 268948 0.219 6 259878834 16397803 6820 6350170 859 0 6527311 3.125 7 7238274884 517155540 412780 92555156 74043 0 161063752 39.38 ------------------------------------------------------------------------------- FEN: 2rkr3/5PP1/8/5Q2/5q2/8/5pp1/2RKR3 w KQkq - 0 1 +-a--b--*--*--*--f--g--h-+ MS Vis.Studio C++ 32-Bit-Vers. 13.10 8 | :::[r][k][r]::: :::| (Compilation: Sep 14 2006) 7 |::: ::: ::: | 6 | ::: ::: ::: :::| Perft Testseries 5 |::: ::: :::<Q>::: | (with TT caching +1024. MB / 4-fold) 4 | ::: ::: [q] :::| TT Access Success +58.0% 3 |::: ::: ::: ::: | 2 | ::: ::: [p][p]:::| Smirf Test No.: 2 1 |::: <R><K><R> ::: | =>+-a--b--*--*--*--f--g--h-+ Break Time: +5.000 Sec. Ply Nodes all (x) (ep) all (+) (#) Prom. Cstl. Sec. ------------------------------------------------------------------------------- 1 51 8 0 11 5 12 0 0 2 1904 295 0 415 97 448 0 0 3 71005 10123 0 14394 2705 14644 30 0 4 2583102 360447 0 535539 73768 530308 2553 0.125 5 94370149 12397325 0 18585139 2282062 16921432 109204 2.797 6 3396258275 435517084 0 680642615 67980443 604077916 5858281 41.42 -------------------------------------------------------------------------------

Regards, Reinhard.

by **Richard Pijl** » 14 Sep 2006, 19:35

Uri Blass wrote:At this time I still have bugs in perft
one of my mistakes was that I assumed that all the squares between the rook and the destination square must be empty like normal chess and it is not the case and here castling is legal.

nr1kqrbn/pbpppppp/1p6/8/8/1P6/PBPPPPPP/NR1KQRBN w KQkq - - 0 1

perft(2) = 670,time=562
perft(3) = 17508
perft(4) = 445979,time=578
perft(5) = 11874666
perft(6) = 313043305,time=4563

Uri

CTD:
W[1]> perft 1
perft=26
W[1]> perft 2
perft=670
W[1]> perft 3
perft=17458
W[1]> perft 4
perft=449368
W[1]> perft 5
perft=12050739
W[1]> perft 6
perft=319767919

by **Uri Blass** » 14 Sep 2006, 23:45

Richard Pijl wrote:
Uri Blass wrote:At this time I still have bugs in perft
one of my mistakes was that I assumed that all the squares between the rook and the destination square must be empty like normal chess and it is not the case and here castling is legal.

nr1kqrbn/pbpppppp/1p6/8/8/1P6/PBPPPPPP/NR1KQRBN w KQkq - - 0 1

perft(2) = 670,time=562
perft(3) = 17508
perft(4) = 445979,time=578
perft(5) = 11874666
perft(6) = 313043305,time=4563

Uri

CTD:
W[1]> perft 1
perft=26
W[1]> perft 2
perft=670
W[1]> perft 3
perft=17458
W[1]> perft 4
perft=449368
W[1]> perft 5
perft=12050739
W[1]> perft 6
perft=319767919

Thanks I found that the problem was in unmaking castling move
unmaking castling move cause situation of king take rook because I look at castling move as the king move.

In normal chess the from square is always empty when I undo moves.

My undomove() starts with
updatepiece(to,from); when the assumption that update is based on is the assumption that from is empty.

c1 was empty when I made the long castling
king d1->c1 but d1 is not empty when I undo the move.

I thought that the fact that the to square is empty is enough to protect me from capturing my own pieces in long castling in this case but it is not enough.

Uri

by **Uri Blass** » 15 Sep 2006, 13:39

Richard Pijl wrote:
Uri Blass wrote:At this time I still have bugs in perft
one of my mistakes was that I assumed that all the squares between the rook and the destination square must be empty like normal chess and it is not the case and here castling is legal.

nr1kqrbn/pbpppppp/1p6/8/8/1P6/PBPPPPPP/NR1KQRBN w KQkq - - 0 1

perft(2) = 670,time=562
perft(3) = 17508
perft(4) = 445979,time=578
perft(5) = 11874666
perft(6) = 313043305,time=4563

Uri

CTD:
W[1]> perft 1
perft=26
W[1]> perft 2
perft=670
W[1]> perft 3
perft=17458
W[1]> perft 4
perft=449368
W[1]> perft 5
perft=12050739
W[1]> perft 6
perft=319767919

After fixing my undomove perft 1-perft 5 are correct
perft 6 is not correct because of lines like the following line
1.d3 a5 2.Qxa5 xxx 3.Qxa8 0-0-0

I think that castling is generally not allowed when the rook is pinned because it can be pinned from only one direction.

After fixing the pin bug I get here correct result for perft 6
I still need to fix king take rook bug in makemove but that bug is not relevant here for perft 6.

Uri

by **Uri Blass** » 15 Sep 2006, 13:51

Reinhard Scharnagl wrote:Here are some numbers from SMIRF (hopefully correct ):

Code: Select all
FEN: nr1kqrbn/pbpppppp/1p6/8/8/1P6/PBPPPPPP/NR1KQRBN w KQkq - 0 1 +-a--*--c--*--e--*--g--h-+ MS Vis.Studio C++ 32-Bit-Vers. 13.10 8 |[n][r] [k][q][r][b][n]| (Compilation: Sep 14 2006) 7 |[p][b][p][p][p][p][p][p]| 6 | [p] ::: ::: :::| Perft Testseries 5 |::: ::: ::: ::: | (with TT caching +1024. MB / 4-fold) 4 | ::: ::: ::: :::| TT Access Success +59.0% 3 |:::::: ::: ::: | 2 || Smirf Test No.: 0 1 |<N><R>:::<K><Q><R><N>| =>+-a--*--c--*--e--*--g--h-+ Break Time: +5.000 Sec. Ply Nodes all (x) (ep) all (+) (#) Prom. Cstl. Sec. ------------------------------------------------------------------------------- 1 26 1 0 0 0 0 1 0 2 670 28 0 1 0 0 26 0 3 17458 814 0 93 0 0 565 0 4 449368 22814 0 2878 0 0 14629 0.016 5 12050739 681668 290 111040 11 0 324894 0.265 6 319767919 19645925 6938 3193732 589 0 8646625 3.562 7 8961813899 606224482 513431 111563740 82528 0 201867319 45.84 ------------------------------------------------------------------------------- FEN: nr1kqrbn/pbpppppp/1p6/8/8/BP6/P1PPPPPP/NR1KQRBN b KQkq - 0 1 =>+-a--*--c--*--e--*--g--h-+ MS Vis.Studio C++ 32-Bit-Vers. 13.10 8 |[n][r] [k][q][r][b][n]| (Compilation: Sep 14 2006) 7 |[p][b][p][p][p][p][p][p]| 6 | [p] ::: ::: :::| Perft Testseries 5 |::: ::: ::: ::: | (with TT caching +1024. MB / 4-fold) 4 | ::: ::: ::: :::| TT Access Success +58.0% 3 |::: ::: ::: | 2 |:::| Smirf Test No.: 1 1 |<N><R>:::<K><Q><R><N>| +-a--*--c--*--e--*--g--h-+ Break Time: +5.000 Sec. Ply Nodes all (x) (ep) all (+) (#) Prom. Cstl. Sec. ------------------------------------------------------------------------------- 1 26 1 0 0 0 0 1 0 2 618 28 0 22 0 0 26 0 3 15681 798 0 84 0 0 502 0 4 382020 20232 0 10744 0 0 12187 0.015 5 10110878 613999 246 94667 12 0 268948 0.219 6 259878834 16397803 6820 6350170 859 0 6527311 3.125 7 7238274884 517155540 412780 92555156 74043 0 161063752 39.38 ------------------------------------------------------------------------------- FEN: 2rkr3/5PP1/8/5Q2/5q2/8/5pp1/2RKR3 w KQkq - 0 1 +-a--b--*--*--*--f--g--h-+ MS Vis.Studio C++ 32-Bit-Vers. 13.10 8 | :::[r][k][r]::: :::| (Compilation: Sep 14 2006) 7 |::: ::: ::: | 6 | ::: ::: ::: :::| Perft Testseries 5 |::: ::: :::<Q>::: | (with TT caching +1024. MB / 4-fold) 4 | ::: ::: [q] :::| TT Access Success +58.0% 3 |::: ::: ::: ::: | 2 | ::: ::: [p][p]:::| Smirf Test No.: 2 1 |::: <R><K><R> ::: | =>+-a--b--*--*--*--f--g--h-+ Break Time: +5.000 Sec. Ply Nodes all (x) (ep) all (+) (#) Prom. Cstl. Sec. ------------------------------------------------------------------------------- 1 51 8 0 11 5 12 0 0 2 1904 295 0 415 97 448 0 0 3 71005 10123 0 14394 2705 14644 30 0 4 2583102 360447 0 535539 73768 530308 2553 0.125 5 94370149 12397325 0 18585139 2282062 16921432 109204 2.797 6 3396258275 435517084 0 680642615 67980443 604077916 5858281 41.42 -------------------------------------------------------------------------------

Regards, Reinhard.

Latest movei can confirm the numbers of nodes in the first 2 positions

In the 3th position it has the same number of nodes at depth 3 but crash at depth 4.

I suspect that the bug of capturing my own pieces in making castling moves is responsible for the problem.

Uri

Winboard Forum

perft result of FRC

perft result of FRC

Re: perft result of FRC

Re: perft result of FRC

Re: perft result of FRC

Re: perft result of FRC

Re: perft result of FRC

Re: perft result of FRC

Re: perft result of FRC

Re: perft result of FRC

Re: perft result of FRC

Re: perft result of FRC

Re: perft result of FRC

Re: perft result of FRC

Re: perft result of FRC

Who is online