bizarre doch move

Discussion of anything and everything relating to chess playing software and machines.

Moderator: Ras

metax
Posts: 344
Joined: Wed Sep 23, 2009 5:56 pm
Location: Germany

Re: bizarre doch move

Post by metax »

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?
User avatar
Eelco de Groot
Posts: 4669
Joined: Sun Mar 12, 2006 2:40 am
Full name:   Eelco de Groot

Re: bizarre doch move

Post by Eelco de Groot »

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?
Hi Luca,

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 :) Max() instead of Min()

Code: Select all

extraDepth = (RootMoveNumber <= 15 ? OnePly + (Max((Iteration >> 1), 4))*OnePly: DEPTH_ZERO);
So the effect, which was already strong, became even stronger... In this position it was not so bad, Stockfish has a null move search which is very fast/efficient but in general I suspect null window searches tend to be slightly pessimistic -unless they see tactics; then they can become wildly optimistic in the first plies and throw the positional sense away with the bathwater :!: - and of course using all sorts of pruning they may miss things. The question is always how sure you are of the PV value and alpha, how much time you are willing to spend on the other moves. And this depends on the amount of time you want to spent in general. This is just very interesting, how the different types of search behave when given more time, questions should nullwindow search be deeper if alpha is negative, now I'm investigating if Null move should change on deeper searches etc.

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
yanquis1972
Posts: 1766
Joined: Wed Jun 03, 2009 12:14 am

Re: bizarre doch move

Post by yanquis1972 »

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
User avatar
Eelco de Groot
Posts: 4669
Joined: Sun Mar 12, 2006 2:40 am
Full name:   Eelco de Groot

1... a4!

Post by Eelco de Groot »

Eelco de Groot wrote:
If the search switches to 1...h6 Stockfish wins :) On efficiency.

Eelco
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:

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