FRC position

Programming Topics (Computer Chess) and technical aspects as test techniques, book building, program tuning etc

Moderator: Andres Valverde

FRC position

Postby milix » 08 Apr 2005, 09:43

Hi all.
Volker Annuss (Herrman) send me a FRC initial position where AICE plays an illegal castling move.

rqkrbnnb/pppppppp/8/8/8/8/PPPPPPPP/RQKRBNNB w KQkq - 0 1
[diag]rqkrbnnb/pppppppp/8/8/8/8/PPPPPPPP/RQKRBNNB w KQkq - 0 1[/diag]

What is your perft for this position? It seems to me that 0-0-0 is not possible if the rook stays in d1.
Anastasios Milikas
milix
 
Posts: 54
Joined: 04 Nov 2004, 19:36
Location: Greece

Re: FRC position

Postby Volker Annuss » 08 Apr 2005, 13:17

Hi Anastasios,

here are Hermanns perft results. The "debug on" is not necessary. It switches on error messages when the FEN string is bad.

Code: Select all
>uci
<[...]
>debug on
>position fen rqkrbnnb/pppppppp/8/8/8/8/PPPPPPPP/RQKRBNNB w KQkq - 0 1
>perft depth 1
<info depth 1 time 0 nodes 20
>perft depth 2
<info depth 2 time 0 nodes 400
>perft depth 3
<info depth 3 time 15 nodes 8832
>perft depth 4
<info depth 4 time 94 nodes 193554
>perft depth 5
<info depth 5 time 2250 nodes 4673537
>perft depth 6
<info depth 6 time 54828 nodes 111825069


For the castling rules, look at Reinhard Scharnagls homepage:
http://www.chessbox.de/Compu/fullchess3_e.html

Castling is permitted only, when nothing is standing from the king to his target square (incl.) except an involved rook, and when nothing is standing from the rook to its target square (incl.) except an involved king (from that it can be concluded, that all the squares must be free between both figures).

The rook on the d-file is not involved in the 0-0-0 castling, so it has to be moved first.

Greetings,
Volker
Volker Annuss
 
Posts: 49
Joined: 25 Jan 2005, 11:14

Re: FRC position

Postby Jaime Benito de Valle » 10 Apr 2005, 22:33

My 5 cents....

....... (depths 1-5) ........

Depth 5
Total: 4673537 Time: 0.655860 s 7125 kNps

Depth 6
Total: 111825069 Time: 12.543344 s 8915 kNps

Depth 7

2916765333 Time: 314.660610 s 9269 kNps

(move by move)

g1f3 123097238 2546 kNps
g1h3 104315113 10586 kNps
f1e3 129236831 4795 kNps
f1g3 106965913 10778 kNps
h2h3 100063439 5944 kNps
h2h4 110892695 10314 kNps
g2g3 152588850 6550 kNps
g2g4 174548427 9902 kNps
f2f3 122923722 7415 kNps
f2f4 140555187 9751 kNps
e2e3 100298471 7933 kNps
e2e4 105834364 9764 kNps
d2d3 194691044 7912 kNps
d2d4 226382994 9640 kNps
c2c3 228298685 8144 kNps
c2c4 234115811 9495 kNps
b2b3 129229194 8647 kNps
b2b4 154309566 9395 kNps
a2a3 128818628 8794 kNps
a2a4 149599161 9247 kNps

Hermann gives the same totals (sort of) up to depth 7.

Please send your results. I'm very interested in any discrepancies from 7 plies on, which is where bugs begin to appear.
By the way, Volker, the version I have for Hermann doesn't display large numbers (%d usually displays 32 bit signed), although the figures are correct after some modifications. Have you corrected this in newer versions?
Regards,
Jaime Benito de Valle Ruiz
User avatar
Jaime Benito de Valle
 
Posts: 27
Joined: 14 Dec 2004, 21:02
Location: Lincoln, England

Re: FRC position

Postby Reinhard Scharnagl » 11 Apr 2005, 02:08

Well, here are Smirf's values:
Code: Select all
FEN: rqkrbnnb/pppppppp/8/8/8/8/PPPPPPPP/RQKRBNNB w KQkq - 0 1

  +-*--b--*--*--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10
8 |[r][q][k][r][b][n][n][b]| (Compilation: Apr 11 2005)
7 |[p][p][p][p][p][p][p][p]|
6 |   :::   :::   :::   :::| Perft Testseries
5 |:::   :::   :::   :::   |
4 |   :::   :::   :::   :::| (without caching)
3 |:::   :::   :::   :::   |
2 |<P><P><P><P><P><P><P><P>| Smirf Test No.: 00
1 |<R><Q><K><R><B><N><N><B>|
=>+-*--b--*--*--e--f--g--h-+ Break Time 5.0 Sec.

Ply     Nodes    all (x)   (e.p.)    all (+) all (++)    Promot.    Castl. Sec.
-------------------------------------------------------------------------------
1          20          0        0          0        0          0         0    0
2         400          0        0          0        0          0         0    0
3        8832         99        0         40        0          0         0    0
4      193554       2961        0        915        0          0         0    0
5     4673537     129047      257      39895        0          0         0  0.2
6   111825069    3793709     5166     983773      145          0         0  4.3
7  2916765333  132941956   314652   35568323     5512          0        37  106
-------------------------------------------------------------------------------

P.S.: less detailed results (using a transposition table):
Code: Select all
FEN: rqkrbnnb/pppppppp/8/8/8/8/PPPPPPPP/RQKRBNNB w KQkq - 0 1

  +-*--b--*--*--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10
8 |[r][q][k][r][b][n][n][b]| (Compilation: Apr 11 2005)
7 |[p][p][p][p][p][p][p][p]|
6 |   :::   :::   :::   :::| Perft Testseries
5 |:::   :::   :::   :::   | (With TT Caching 256.0 MB / 4-fold)
4 |   :::   :::   :::   :::| TT Access Success 47.9%
3 |:::   :::   :::   :::   |
2 |<P><P><P><P><P><P><P><P>| Smirf Test No.: 00
1 |<R><Q><K><R><B><N><N><B>|
=>+-*--b--*--*--e--f--g--h-+ Break Time 20.0 Sec.

Ply           Nodes          all (x)          all (+)         (e.p.)    Sec.
----------------------------------------------------------------------------
1                20                0                0              0       0
2               400                0                0              0       0
3              8832               99               40              0       0
4            193554             2961              915              0       0
5           4673537           129047            39895            257     0.1
6         111825069          3793709           983773           5166     1.2
7        2916765333        132941956         35568323         314652    14.5
8       75331645146       3972680374        941690347        6936954   192.9
----------------------------------------------------------------------------

Regards, Reinhard
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Re: FRC position

Postby Volker Annuss » 11 Apr 2005, 08:43

Jaime Benito de Valle wrote:By the way, Volker, the version I have for Hermann doesn't display large numbers (%d usually displays 32 bit signed), although the figures are correct after some modifications. Have you corrected this in newer versions?


The current version Hermann 1.3.5 uses a 64 bit counter.

Greetings,
Volker
Volker Annuss
 
Posts: 49
Joined: 25 Jan 2005, 11:14

Re: FRC position

Postby Reinhard Scharnagl » 14 Apr 2005, 18:03

Hi all,

there still are no verifications for the results of higher plys of that position.

After improving my cache using perft variant I add an extended statistic
including figures for promotion moves too.

Regards, Reinhard.
Code: Select all
FEN: rqkrbnnb/pppppppp/8/8/8/8/PPPPPPPP/RQKRBNNB w KQkq - 0 1

  +-*--b--*--*--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10
8 |[r][q][k][r][b][n][n][b]| (Compilation: Apr 14 2005)
7 |[p][p][p][p][p][p][p][p]|
6 |   :::   :::   :::   :::| Perft Testseries
5 |:::   :::   :::   :::   | (With TT Caching 256.0 MB / 4-fold)
4 |   :::   :::   :::   :::| TT Access Success 38.2%
3 |:::   :::   :::   :::   |
2 |<P><P><P><P><P><P><P><P>| Smirf Test No.: 00
1 |<R><Q><K><R><B><N><N><B>|
=>+-*--b--*--*--e--f--g--h-+ Break Time 200.0 Sec.

Ply        Nodes      all (x)    (e.p.)       all (+)     Promot.     Castl.  Sec.
----------------------------------------------------------------------------------
1             20            0         0             0           0          0     0
2            400            0         0             0           0          0     0
3           8832           99         0            40           0          0     0
4         193554         2961         0           915           0          0     0
5        4673537       129047       257         39895           0          0   0.1
6      111825069      3793709      5166        983773           0          0   1.2
7     2916765333    132941956    314652      35568323           0         37  14.4
8    75331645146   3972680374   6936954     941690347           0      12204 192.5
9  2093941843698 132045270050 304280183   32619777466    16808712  204861015  4492
----------------------------------------------------------------------------------

P.S.: I am not sure about the last line. A newer result has been:
Code: Select all
Ply        Nodes       all (x)     (e.p.)     all (+)    Prom.    Castl.   Sec.
-------------------------------------------------------------------------------
1             20             0          0           0        0         0      0
2            400             0          0           0        0         0      0
3           8832            99          0          40        0         0      0
4         193554          2961          0         915        0         0      0
5        4673537        129047        257       39895        0         0    0.1
6      111825069       3793709       5166      983773        0         0    1.3
7     2916765333     132941956     314652    35568323        0        37   14.8
8    75331645146    3972680374    6936954   941690347        0     12204  188.1
9  2093941558902  132045250042  304280172 32619775942 16808712 204860899   3074
-------------------------------------------------------------------------------

Regards, Reinhard.
Last edited by Reinhard Scharnagl on 15 Apr 2005, 19:09, edited 1 time in total.
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Re: FRC position

Postby Sune Fischer » 14 Apr 2005, 22:06

Hi Reinhard,

Frenzee gets the same up to and including ply 8, I haven't tried ply 9.

There are better testpostions for FRC though, I have used the following
which have been confirmed by another frc engine:

[FRC - Perft]
Rr3kr1/2p2ppp/2nbp1n1/3p4/1pB1q1b1/1P2P1N1/1PPP1PPP/1NB1QKR1 b Kkq - 0 1
perft 1 47
perft 2 1335
perft 3 60626
perft 4 1754084
perft 5 79306332
perft 6 2336234512

1r1k1r2/ppp1bppp/2np3q/4p3/b1B3Q1/N2PP1Pn/PPPB1P1P/1R1K1R2 w KQkq - 0 1
perft 1 42
perft 2 1533
perft 3 58858
perft 4 2208844
perft 5 82619281
perft 6 3163057546

One particular bug I remember finding was the long castle for black in the
first position. This kind of castling into check is only possible in FRC.

-S.
User avatar
Sune Fischer
 
Posts: 126
Joined: 07 Oct 2004, 11:12
Location: Denmark

Re: FRC position

Postby Reinhard Scharnagl » 14 Apr 2005, 23:23

Hi Sune,

thank you for your posting! In exchange I can verify your figures:
Code: Select all
FEN: Rr3kr1/2p2ppp/2nbp1n1/3p4/1pB1q1b1/1P2P1N1/1PPP1PPP/1NB1QKR1 b Kkq - 0 1

=>+-a--*--c--d--e--*--*--h-+ MS Vis. Studio C++ Vers. 13.10
8 |<R>[r]   :::   [k][r]:::| (Compilation: Apr 15 2005)
7 |:::   [p]   :::[p][p][p]|
6 |   :::[n][b][p]:::[n]:::| Perft Testseries
5 |:::   :::[p]:::   :::   | (With TT Caching 512.0 MB / 4-fold)
4 |   [p]<B>:::[q]:::[b]:::| TT Access Success 57.9%
3 |:::<P>:::   <P>   <N>   |
2 |   <P><P><P>   <P><P><P>| Smirf Test No.: 00
1 |:::<N><B>   <Q><K><R>   |
  +-a--b--c--d--e--*--*--h-+ Break Time 30.0 Sec.

Ply        Nodes       all (x)    (e.p.)     all (+)    Prom.      Castl.  Sec.
-------------------------------------------------------------------------------
1             47             7         0           4        0           1     0
2           1335           151         0          40        0          43     0
3          60626          9240         1        4310        0        1409     0
4        1754084        221862         0       41138        0       51759   0.1
5       79306332      12483752     10861     5047355        0     1789561   1.3
6     2336234512     323467817      1379    49627186        0    62359539  22.9
7   104503613557   17032580975  20913802  6205691323  2817344  2158010800 388.3
-------------------------------------------------------------------------------


FEN: 1r1k1r2/ppp1bppp/2np3q/4p3/b1B3Q1/N2PP1Pn/PPPB1P1P/1R1K1R2 w KQkq - 0 1

  +-a--*--c--*--e--*--g--h-+ MS Vis. Studio C++ Vers. 13.10
8 |   [r]   [k]   [r]   :::| (Compilation: Apr 15 2005)
7 |[p][p][p]   [b][p][p][p]|
6 |   :::[n][p]   :::   [q]| Perft Testseries
5 |:::   :::   [p]   :::   | (With TT Caching 512.0 MB / 4-fold)
4 |[b]:::<B>:::   :::<Q>:::| TT Access Success 54.5%
3 |<N>   :::<P><P>   <P>[n]|
2 |<P><P><P><B>   <P>   <P>| Smirf Test No.: 01
1 |:::<R>:::<K>:::<R>:::   |
=>+-a--*--c--*--e--*--g--h-+ Break Time 30.0 Sec.

Ply        Nodes       all (x)   (e.p.)      all (+)   Prom.       Castl.  Sec.
-------------------------------------------------------------------------------
1             42             3        0            2       0            1     0
2           1533           150        0           86       0           48     0
3          58858          6451        0         2442       0         1281     0
4        2208844        263066       34       128667       0        60664   0.1
5       82619281      11033942      124      3337584       0      1547446   1.5
6     3163057546     422595743    80606    183100448       0     73264323  26.8
7   116684109110   17568516847   474555   4813234553       0   1831394581 485.7
-------------------------------------------------------------------------------

Indeed, in the first example the long castling is initially impossible, because the involved rook b8 is pinned. Though moving along the direction of pinning, castling is impossible, because the king would face a check threat. Such a situation is indeed possible only in Chess960 (or in CRC, Capablanca Random Chess).

Regards, Reinhard.

P.S.: Oh, I noticed, that the captions of the colums have been misplaced, sorry. I have done a correction here.
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Re: FRC position

Postby Sune Fischer » 15 Apr 2005, 07:12

Hi Reinhard,

Good that Smirf agress :)

I was thinking one should really also mirror the board and check that all 4
versions produce the same count.

Btw, what is the interpretation of the position when two rooks are on the
same side of the king, and he still has castle rights for that side?
I remember some time ago there was a discussion on this, but I don't
recall the outcome.

It doesn't seem possible to know this without the game
history, much like the problem with repetitions and 50 move counter.

We might see engines differ in perft here depending on their choice of
castling rook.

-S.
User avatar
Sune Fischer
 
Posts: 126
Joined: 07 Oct 2004, 11:12
Location: Denmark

Re: FRC position

Postby Reinhard Scharnagl » 15 Apr 2005, 14:23

Hi Sune,
Sune wrote:Btw, what is the interpretation of the position when two rooks are on the
same side of the king, and he still has castle rights for that side?
I remember some time ago there was a discussion on this, but I don't
recall the outcome.

a) if a game has been played, the history will clear things up.
b) if nothing is specified except the castling side in the FEN, the OUTERMOST rook is affected.
c) if an inner rook should posses the castling right, the FILE LETTER of the affected rook has to FOLLOW its castling symbol in the FEN.

Here is an example (watch, that the castling rights also are marked by stars within the board's border):
Code: Select all
FEN: r2k3r/8/8/8/8/8/8/3K2RR w Kgq - 0 1

  +-*--b--c--*--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10
8 |[r]:::   [k]   :::   [r]| (Compilation: Apr 15 2005)
7 |:::   :::   :::   :::   | Testscenario (sorted, O(n*log(n))):
6 |   :::   :::   :::   :::| Move generation
5 |:::   :::   :::   :::   |
4 |   :::   :::   :::   :::| Smirf Test No.: 00
3 |:::   :::   :::   :::   |
2 |   :::   :::   :::   :::| Move Count:  22*3306712
1 |:::   :::<K>:::   <R><R>| per Second:  22383896
=>+-a--b--c--*--e--f--*--h-+ Time:        3.250 sec

  5.695 Rh1xh8+  0.887 Rg1-g8+  0.445 Rg1-g7   0.438 O-O      0.402 Rg1-g6
  0.391 Rh1-h7   0.359 Rh1-h6   0.336 Rg1-g5   0.305 Rh1-h5   0.262 Rg1-g4
  0.238 Rh1-h4   0.180 Rg1-g3   0.164 Rh1-h3   0.098 Kd1-d2   0.090 Kd1-e2
  0.090 Rg1-g2   0.090 Kd1-c2   0.082 Rh1-h2   0.055 Rg1-e1   0.035 Rg1-f1
 -0.008 Kd1-e1  -0.008 Kd1-c1


FEN: r2k3r/8/8/8/8/8/8/3K2RR w Kq - 0 1

  +-*--b--c--*--e--f--g--h-+ MS Vis. Studio C++ Vers. 13.10
8 |[r]:::   [k]   :::   [r]| (Compilation: Apr 15 2005)
7 |:::   :::   :::   :::   | Testscenario (sorted, O(n*log(n))):
6 |   :::   :::   :::   :::| Move generation
5 |:::   :::   :::   :::   |
4 |   :::   :::   :::   :::| Smirf Test No.: 01
3 |:::   :::   :::   :::   |
2 |   :::   :::   :::   :::| Move Count:  21*3464175
1 |:::   :::<K>:::   <R><R>| per Second:  25861242
=>+-a--b--c--*--e--f--g--*-+ Time:        2.813 sec

  5.695 Rh1xh8+  0.887 Rg1-g8+  0.445 Rg1-g7   0.402 Rg1-g6   0.391 Rh1-h7
  0.359 Rh1-h6   0.336 Rg1-g5   0.305 Rh1-h5   0.262 Rg1-g4   0.238 Rh1-h4
  0.180 Rg1-g3   0.164 Rh1-h3   0.098 Kd1-d2   0.090 Rg1-g2   0.090 Kd1-c2
  0.090 Kd1-e2   0.082 Rh1-h2   0.055 Rg1-e1   0.035 Rg1-f1  -0.008 Kd1-e1
 -0.008 Kd1-c1

Regards, Reinhard.
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany

Re: FRC position

Postby Jaime Benito de Valle » 15 Apr 2005, 18:26

Sune Fischer wrote:[FRC - Perft]
Rr3kr1/2p2ppp/2nbp1n1/3p4/1pB1q1b1/1P2P1N1/1PPP1PPP/1NB1QKR1 b Kkq - 0 1
perft 1 47
perft 2 1335
perft 3 60626
perft 4 1754084
perft 5 79306332
perft 6 2336234512

1r1k1r2/ppp1bppp/2np3q/4p3/b1B3Q1/N2PP1Pn/PPPB1P1P/1R1K1R2 w KQkq - 0 1
perft 1 42
perft 2 1533
perft 3 58858
perft 4 2208844
perft 5 82619281
perft 6 3163057546


Thanks Sune for your suggestion: I've found a bug that would have been almost impossible to find by trying a typical starting position like the ones we usually post here. I realized almost instantly what the problem was when I saw that rook on A8 next to the black's castling line... so I corrected it quicly.
My results now match yours and Reinhard's

Depth 1 Nodes: 47
Depth 2 Nodes: 1335
Depth 3 Nodes: 60626
Depth 4 Nodes: 1754084
Depth 5 Nodes: 79306332
Depth 6 Nodes: 2336234512

Depth 1 Nodes: 42
Depth 2 Nodes: 1533
Depth 3 Nodes: 58858
Depth 4 Nodes: 2208844
Depth 5 Nodes: 82619281
Depth 6 Nodes: 3163057546

Regards,

Jaime

P.S. - Hermann (engine) gives the same figures
Jaime Benito de Valle Ruiz
User avatar
Jaime Benito de Valle
 
Posts: 27
Joined: 14 Dec 2004, 21:02
Location: Lincoln, England

Re: FRC position

Postby Volker Annuss » 16 Apr 2005, 17:02

Hermann 1.3.7 is available for testers at http://www.nnuss.de/Hermann/Hermann137.zip

It has a new command
Code: Select all
uci
debug on
position fen <fen-string>
perft depth <d> Hash <m>
or
Code: Select all
perft Hash <m> depth <d>

where <m> is the size of a hash table in megabytes. The old perft command without hash still works.

Please do not use this version in tournaments.

Greetings,
Volker
Volker Annuss
 
Posts: 49
Joined: 25 Jan 2005, 11:14

Re: FRC position

Postby milix » 16 Apr 2005, 18:48

Hi, I have the same perft numbers for Sune's positions.
Also in AICE 0.92 I have a new command for perft in an epd file:
Code: Select all
perft <depth> [epdfile]


This command calculates the perft for depth <depth> for all positions in the epd-file.
Anastasios Milikas
milix
 
Posts: 54
Joined: 04 Nov 2004, 19:36
Location: Greece

Re: FRC position

Postby Reinhard Scharnagl » 16 Apr 2005, 21:15

Hi all,
Sune wrote:I was thinking one should really also mirror the board and check that all 4 versions produce the same count.

Mirroring left to right would not work because of the asymmetric nature of castling. But switching the position up to down with changing all colors should give positions with identic perft countings. I did it for both positions:
Code: Select all
FEN: Rr3kr1/2p2ppp/2nbp1n1/3p4/1pB1q1b1/1P2P1N1/1PPP1PPP/1NB1QKR1 b Kkq - 0 1

=>+-a--*--c--d--e--*--*--h-+ MS Vis. Studio C++ Vers. 13.10
8 |<R>[r]   :::   [k][r]:::| (Compilation: Apr 16 2005)
7 |:::   [p]   :::[p][p][p]|
6 |   :::[n][b][p]:::[n]:::| Perft Testseries
5 |:::   :::[p]:::   :::   | (With TT Caching 256.0 MB / 4-fold)
4 |   [p]<B>:::[q]:::[b]:::| TT Access Success 55.4%
3 |:::<P>:::   <P>   <N>   |
2 |   <P><P><P>   <P><P><P>| Smirf Test No.: 00
1 |:::<N><B>   <Q><K><R>   |
  +-a--b--c--d--e--*--*--h-+ Break Time 5.0 Sec.

Ply       Nodes      all (x)    (e.p.)     all (+)    Prom.     Castl.     Sec.
-------------------------------------------------------------------------------
1            47            7         0           4        0          1        0
2          1335          151         0          40        0         43        0
3         60626         9240         1        4310        0       1409        0
4       1754084       221862         0       41138        0      51759      0.1
5      79306332     12483752     10861     5047355        0    1789561      1.3
6    2336234512    323467817      1379    49627186        0   62359539     22.1
-------------------------------------------------------------------------------


FEN: 1nb1qkr1/1ppp1ppp/1p2p1n1/1Pb1Q1B1/3P4/2NBP1N1/2P2PPP/rR3KR1 w KQk - 0 1

  +-a--b--c--d--e--*--*--h-+ MS Vis. Studio C++ Vers. 13.10
8 |   [n][b]:::[q][k][r]:::| (Compilation: Apr 16 2005)
7 |:::[p][p][p]:::[p][p][p]|
6 |   [p]   :::[p]:::[n]:::| Perft Testseries
5 |:::<P>[b]   <Q>   <B>   | (With TT Caching 256.0 MB / 4-fold)
4 |   :::   <P>   :::   :::| TT Access Success 55.5%
3 |:::   <N><B><P>   <N>   |
2 |   :::<P>:::   <P><P><P>| Smirf Test No.: 01
1 |[r]<R>:::   :::<K><R>   |
=>+-a--*--c--d--e--*--*--h-+ Break Time 5.0 Sec.

Ply       Nodes      all (x)    (e.p.)     all (+)    Prom.     Castl.     Sec.
-------------------------------------------------------------------------------
1            47            7         0           4        0          1        0
2          1335          151         0          40        0         43        0
3         60626         9240         1        4310        0       1409        0
4       1754084       221862         0       41138        0      51759      0.1
5      79306332     12483752     10861     5047355        0    1789561      1.3
6    2336234512    323467817      1379    49627186        0   62359539     22.3
-------------------------------------------------------------------------------


FEN: 1r1k1r2/ppp1bppp/2np3q/4p3/b1B3Q1/N2PP1Pn/PPPB1P1P/1R1K1R2 w KQkq - 0 1

  +-a--*--c--*--e--*--g--h-+ MS Vis. Studio C++ Vers. 13.10
8 |   [r]   [k]   [r]   :::| (Compilation: Apr 16 2005)
7 |[p][p][p]   [b][p][p][p]|
6 |   :::[n][p]   :::   [q]| Perft Testseries
5 |:::   :::   [p]   :::   | (With TT Caching 256.0 MB / 4-fold)
4 |[b]:::<B>:::   :::<Q>:::| TT Access Success 57.9%
3 |<N>   :::<P><P>   <P>[n]|
2 |<P><P><P><B>   <P>   <P>| Smirf Test No.: 02
1 |:::<R>:::<K>:::<R>:::   |
=>+-a--*--c--*--e--*--g--h-+ Break Time 5.0 Sec.

Ply       Nodes      all (x)    (e.p.)      all (+)   Prom.     Castl.     Sec.
-------------------------------------------------------------------------------
1            42            3         0            2       0          1        0
2          1533          150         0           86       0         48        0
3         58858         6451         0         2442       0       1281        0
4       2208844       263066        34       128667       0      60664      0.1
5      82619281     11033942       124      3337584       0    1547446      1.5
6    3163057546    422595743     80606    183100448       0   73264323     26.3
-------------------------------------------------------------------------------


FEN: 1r1k1r2/pppb1p1p/n2pp1pN/B1b3q1/4P3/2NP3Q/PPP1BPPP/1R1K1R2 b KQkq - 0 1

=>+-a--*--c--*--e--*--g--h-+ MS Vis. Studio C++ Vers. 13.10
8 |   [r]   [k]   [r]   :::| (Compilation: Apr 16 2005)
7 |[p][p][p][b]:::[p]:::[p]|
6 |[n]:::   [p][p]:::[p]<N>| Perft Testseries
5 |<B>   [b]   :::   [q]   | (With TT Caching 256.0 MB / 4-fold)
4 |   :::   :::<P>:::   :::| TT Access Success 57.9%
3 |:::   <N><P>:::   :::<Q>|
2 |<P><P><P>:::<B><P><P><P>| Smirf Test No.: 03
1 |:::<R>:::<K>:::<R>:::   |
  +-a--*--c--*--e--*--g--h-+ Break Time 5.0 Sec.

Ply       Nodes      all (x)    (e.p.)      all (+)   Prom.     Castl.     Sec.
-------------------------------------------------------------------------------
1            42            3         0            2       0          1        0
2          1533          150         0           86       0         48        0
3         58858         6451         0         2442       0       1281        0
4       2208844       263066        34       128667       0      60664      0.1
5      82619281     11033942       124      3337584       0    1547446      1.5
6    3163057546    422595743     80606    183100448       0   73264323     26.0
-------------------------------------------------------------------------------

Volker wrote:... where <m> is the size of a hash table in megabytes.

It is great to see another perft and cache combination!

Regards, Reinhard.
Reinhard Scharnagl
 
Posts: 608
Joined: 01 Oct 2004, 08:36
Location: Klein-Gerau, Germany


Return to Programming and Technical Discussions

Who is online

Users browsing this forum: No registered users and 39 guests