bizarre doch move
Moderator: Ras
-
- Posts: 344
- Joined: Wed Sep 23, 2009 5:56 pm
- Location: Germany
Re: bizarre doch move
May I ask why the node counts of Rainbow Serpent, which I remember to be based on Stockfish, are so extremely high already for the first iterations? 2.5M nodes for ply 5 seem to be very much... Have I missed something?
-
- Posts: 4669
- Joined: Sun Mar 12, 2006 2:40 am
- Full name: Eelco de Groot
Re: bizarre doch move
Hi Luca,metax wrote:May I ask why the node counts of Rainbow Serpent, which I remember to be based on Stockfish, are so extremely high already for the first iterations? 2.5M nodes for ply 5 seem to be very much... Have I missed something?
Yes, well that was partly non intentional at least for the last build, build 99. Depths for the null window searches, with which all the other Root moves but the first are searched are going up faster than for the PV move. I wanted to limit that in this version, so depth for null window would be maximally four plies larger. But instead I used code so it is minimally four plies larger

Code: Select all
extraDepth = (RootMoveNumber <= 15 ? OnePly + (Max((Iteration >> 1), 4))*OnePly: DEPTH_ZERO);

Actually I kind of liked the accidental five ply null window searches here, it was just doable. What happens in those very first plies can affect the search later on, optimizing this is one of the secrets of Rybka. Vas finally admitted there is such a 'Butterfly effect' more than a year ago, maybe two it was , after first claiming this was all just very basic engineering and deterministic behaviour. Old Rebel veterans knew better of course

There are extensions in the PV search as well but they are not so strong because I let most of it start at a deeper branching point, if the branch is the right one i.e. it follows the PV also on deeper searches I gained a lot of time. The code is in Dancing Dragon to be found on the Toga Bulletin Board TDBB. Denis made a MSVC 2008 compile for me which he can do remotely, by phone, or SMS instructions, to his wife. They are amazing

Regards,
Eelco
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
-
- Posts: 1766
- Joined: Wed Jun 03, 2009 12:14 am
Re: bizarre doch move
shredder barely considers 0-0 and drops it out of the top3 pretty quickly
16 0:48 +0.31 1.g3 Rg8 2.gxf4 Rg6 3.f5 Rh6 4.Qg4 Bxd5 5.exd5 Rh4 6.Qg2 Nd4 7.c3 b4 8.cxb4 Qb6 9.O-O Qxb4 10.Rab1
16 0:51 +0.05 1.Rg1 Rg8 2.c3 Rg5 3.Qd1 Bg7 4.Nc2 Kf8 5.h4 Rg4 6.a4 bxa4 7.h5 Kg8 8.Rxa4 a5 9.Bb5 Na7 10.Be2 Rg5
16 0:52 +0.05 1.c3 Rg8 2.Rg1 Rg5 3.Qd1 Bg7 4.Nc2 Kf8 5.h4 Rg4 6.a4 bxa4 7.h5 Kg8 8.Rxa4 a5 9.Bb5 Na7 10.Be2 Rg5
average search depth 16 half-moves after 0:52 min; evaluation +0.31 means the position is even
rybka 1pv 18 0:49 +0.22 1.O-O Rg8 2.c3 Rg6 3.h3 Rh6 4.Qf3 Rc8 5.Kh1 Qg5 6.Be2 Bxd5 7.exd5 Ne7 8.Kg1 Rc5 9.Rfd1 Rg6 10.Qe4 Bg7 11.Nc2 Kf8 12.Nb4
average search depth 18 half-moves after 0:48 min; evaluation +0.22 means the position is even
16 0:48 +0.31 1.g3 Rg8 2.gxf4 Rg6 3.f5 Rh6 4.Qg4 Bxd5 5.exd5 Rh4 6.Qg2 Nd4 7.c3 b4 8.cxb4 Qb6 9.O-O Qxb4 10.Rab1
16 0:51 +0.05 1.Rg1 Rg8 2.c3 Rg5 3.Qd1 Bg7 4.Nc2 Kf8 5.h4 Rg4 6.a4 bxa4 7.h5 Kg8 8.Rxa4 a5 9.Bb5 Na7 10.Be2 Rg5
16 0:52 +0.05 1.c3 Rg8 2.Rg1 Rg5 3.Qd1 Bg7 4.Nc2 Kf8 5.h4 Rg4 6.a4 bxa4 7.h5 Kg8 8.Rxa4 a5 9.Bb5 Na7 10.Be2 Rg5
average search depth 16 half-moves after 0:52 min; evaluation +0.31 means the position is even
rybka 1pv 18 0:49 +0.22 1.O-O Rg8 2.c3 Rg6 3.h3 Rh6 4.Qf3 Rc8 5.Kh1 Qg5 6.Be2 Bxd5 7.exd5 Ne7 8.Kg1 Rc5 9.Rfd1 Rg6 10.Qe4 Bg7 11.Nc2 Kf8 12.Nb4
average search depth 18 half-moves after 0:48 min; evaluation +0.22 means the position is even
-
- Posts: 4669
- Joined: Sun Mar 12, 2006 2:40 am
- Full name: Eelco de Groot
1... a4!
No switch to 1... h6! The internal depth was somewhere between 22 and 26 plies. Now 1987 minutes into the search but I did get another PV:Eelco de Groot wrote:
If the search switches to 1...h6 Stockfish winsOn efficiency.
Eelco
r3k2r/4bp1p/2bp1p2/p1q1pP2/1pB1P2Q/1P3N2/P1P3PP/1K1R3R b kq -
15.01 1915:19-0.52 1...a4 2.Rhe1 axb3 3.cxb3 Qa7 4.Rd2 Qb7
5.Rc2 Ra5 6.Nd2 h6 7.Bd5 Bxd5 8.exd5 Rxd5
9.Ne4 Qd7 10.Qg4 Kf8 11.Rec1 Bd8
12.Rc8 Rd4 13.R1c7 (54.407.899.412) 473
So the -0.76 for 1... a4 was just at the lower limit of the search window but a4 managed to stay balanced on the window sill and did not fall off, figuratively speaking, with the eval increasing from -0.54 at thirteen ply to -0.52 at fifteen ply.
Eelco
Debugging is twice as hard as writing the code in the first
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan
place. Therefore, if you write the code as cleverly as possible, you
are, by definition, not smart enough to debug it.
-- Brian W. Kernighan