Position in Rybka vs. Diep

[Eelco de Groot]

11 846:08 +1.79 38...Qe2+ 39.Kh1 b3 40.Rf1 Qd3
41.Kh2 Qc2+ 42.Kh1 Qe4+ 43.Kh2 Qe5+
44.Kh1 Qg3 45.Qd7 bxa2 46.Rbd1 Rxb2
47.Qxf7+ Kh8 48.Qe8+ Kh7 49.Rxd5 Qxh3+
50.Kg1 (23.131.399.614) 455

Eelco

What does the 11 mean here? Surely you searched more than eleven plies in that amount of time. In fact the PV is longer than that.

Anyhow, Stockfish thinks that 46.Ra1 would give white equality, at least as deeply as my poor computer can think in thirty minutes.

Hello Greg,

Yes it is possible I am having some trouble with the PVs. I can't do much testing of that as the computer is still churning on, and the main evaluation is still at +1.79 for Black. By ways of transposition the computer now thinks this figure can be reached with three different moves. See below.

It is possible some new evaluation calculations are wrong, I am trying a second step of lazy eval in this build, after the piece evaluation and passed pawn evaluation but cutting short the King safety, especially in the endgame with both sides having less than six pieces and King safety is hopefully not an issue, not enough if the rest of the evaluation is already low.

So what I am trying new in this version is

Code: Select all

  // eval

   eval_piece(board,mat_info,pawn_info,&opening,&endgame);
   eval_passer(board,pawn_info,mat_info,&opening,&endgame);

	/* lazy Cutoff II */

   if (LazyEval && board->piece_size[White] < 6 && board->piece_size[Black] < 6 && alpha < ValueRook){

	 phase = mat_info->phase;
     lazy_eval = ((opening * (256 - mat_info->phase)) + (endgame * mat_info->phase)) / 256;

     ASSERT(eval>=-ValueEvalInf&&eval<=+ValueEvalInf);

	 if (COLOUR_IS_BLACK(board->turn)) lazy_eval = -lazy_eval;
	 if (lazy_eval - lazy_eval_cutoff_II >= beta)
		return (lazy_eval);
	 if (lazy_eval + lazy_eval_cutoff_II <= alpha)
		return (lazy_eval);  
	 // end of second stage lazy cutoff 
   } 


   eval_king(board,mat_info,&opening,&endgame);

If the alpha in the node to be (lazy-) evaluated is good however I thought it may be better to do a full eval, because the eval terms here may be large and getting a better eval would lead to faster wins, so also I introduced the condition that alpha has to be < ValueRook. Not tested yet.

Another very little tested feature although present in many versions already, from build 376 to 419 is that in every PV node I'm doing a series of null window searches before going deeper to the next PV node call of search_full, this does not give me a value but hopefully a better ordered tree from every PV node. But this is costly and maybe not error proof. It could be a source of any faulty PVs?

The iteration 11 that you are seeing is mostly really 11 plies but there are the null window searches and every PV node can also be extended by singular extensions, till after the nominal search depth of 11 plies so often this way the PV could be extended to 22 plies or so, only for PV nodes.

The largest part of the cost of this deep search you are seeing is however that every non-PV root move, so that is 35 moves excluding the three moves seen in the PVs, are searched much deeper. If the nominal depth for the PV is eleven plies, those 35 moves are now searched to 19 plies deep. This becomes expensive with small hashtables and very deep seaches as I am doing here for testing, but it ensures the three moves in the three best PVs are with good probabilty the best, even though these are searched with much shallower searches.

Because this process of searching the non-PV root moves to great depth is done with null window searches, the effect on the branching factor is actually bearable, the effect of singular extensions in PV searches is, to my mind, more a problem although the PV searches are seven to eight plies shallower, without singular extensions. A program spending 50% to 90% in its PV, just to get an alpha that in theory might only apply locally for this bestmove whenever it is not really your best move, I think that Rybka has left all of us behind there

So this process is where the twelve plies in 1088 minutes is coming from. You may think it is a joke Greg, but I'm very serious about it !


[d]1r4k1/5pp1/7p/3p4/Qpp5/5q1P/PP5K/1R1R4 b - -

Engine: Blueberry Beta 4 DM70 Build 419 (Athlon 2009 MHz, 256 MB)
by F. Letouzey, T. Gaksch, E. de Groot

11 846:08 +1.79 38...Qe2+ 39.Kh1 b3 40.Rf1 Qd3
41.Kh2 Qc2+ 42.Kh1 Qe4+ 43.Kh2 Qe5+
44.Kh1 Qg3 45.Qd7 bxa2 46.Rbd1 Rxb2
47.Qxf7+ Kh8 48.Qe8+ Kh7 49.Rxd5 Qxh3+
50.Kg1 (23.131.399.614) 450

11 1087:20 +1.79 38...Qf2+ 39.Kh1 b3 40.a3 Qf5
41.Kh2 Qe5+ 42.Kh1 Qe6 43.Qa7 Qxh3+
44.Kg1 Qg4+ 45.Kh1 Qh4+ 46.Kg1 Qg3+
47.Kf1 Rd8 48.Qf2 Qh3+ 49.Kg1
(29.413.154.824) 450

11 1087:55 +1.79 38...b3 39.Rf1 Qe2+ 40.Kh1 Qd3
41.Kh2 Qc2+ 42.Kh1 Qe4+ 43.Kh2 Qe5+
44.Kh1 Qg3 45.Qd7 bxa2 46.Rbd1 Rxb2
47.Qxf7+ Kh8 48.Qe8+ Kh7 49.Rxd5 Qxh3+
50.Kg1 (29.431.103.881) 450
__________________________________________________

12 1088:03 +1.79 38...Qe2+ 39.Kh1 b3 40.a3 Qe4+
41.Kh2 Qe5+ 42.Kh1 Qe6 43.Qa7 Qxh3+
44.Kg1 Qg4+ 45.Kh1 Qh4+ 46.Kg1 Qg3+
47.Kf1 Rd8 48.Qf2 Qh3+ 49.Kg1 (29.434.780.361) 450



Okay, the PV being inaccurate as you point out is certainly a possible problem, the extension with null window searches is at the moment my main worry there. On the other hand I don't think the +1.79 value could be totally wrong unless I am making serious evalution errors.

Eelco