Stockfish 1.7.1 update available

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

Moderators: Harvey Williamson, Dann Corbit, hgm

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
mcostalba
Posts: 2684
Joined: Sat Jun 14, 2008 7:17 pm

Re: Stockfish 1.7.1 update available

Post by mcostalba » Sat Apr 17, 2010 9:33 am

Eelco de Groot wrote: I'm trying my idea of only storing the verification search results
This could be interesting. Thanks Eelco, I will test it ;-)

mcostalba
Posts: 2684
Joined: Sat Jun 14, 2008 7:17 pm

Re: Stockfish 1.7.1 update available

Post by mcostalba » Sat Apr 17, 2010 10:10 am

mcostalba wrote:
Eelco de Groot wrote: I'm trying my idea of only storing the verification search results
This could be interesting. Thanks Eelco, I will test it ;-)
Well, thinking a bit better it could be not....if you do something like:

Code: Select all

 // Do zugzwang verification search
Value v = search(pos, ss, beta, depth-5*OnePly, ply, false, threadID);
if (v >= beta)
{
     TT.store(posKey, value_to_tt(v, ply), VALUE_TYPE_LOWER, depth-5*OnePly, MOVE_NONE);
     return nullValue;
}
I would think it is redundant because the TT score has been already saved inside search() call.

User avatar
Eelco de Groot
Posts: 4277
Joined: Sun Mar 12, 2006 1:40 am
Location: Groningen

Re: Stockfish 1.7.1 update available

Post by Eelco de Groot » Sat Apr 17, 2010 2:07 pm

mcostalba wrote:
mcostalba wrote:
Eelco de Groot wrote: I'm trying my idea of only storing the verification search results
This could be interesting. Thanks Eelco, I will test it ;-)
Well, thinking a bit better it could be not....if you do something like:

Code: Select all

 // Do zugzwang verification search
Value v = search(pos, ss, beta, depth-5*OnePly, ply, false, threadID);
if (v >= beta)
{
     TT.store(posKey, value_to_tt(v, ply), VALUE_TYPE_LOWER, depth-5*OnePly, MOVE_NONE);
     return nullValue;
}
I would think it is redundant because the TT score has been already saved inside search() call.
Hi Marco,

Yes, I suppose that you are right, it is at least redundant to store it this way for further searches, because you have no new information to store.

I have not really thought about what the code does, because this was just the first try to see if I could reduce those 60 error warnings for one missing semicolon;

It is still the same piece of code I thought up when the null move discussion came up after Uri's bugreport, if there should be a 1.7.1 version.

Until yesterday I had nothing to compile, I was just merging the 1.7.1 with Dann's code and my own changes, so of any piece of code there were at least three different versions, if only outlining changes for most of the reported differences, but the outlining and I think maybe tabstops misinterpreted by Windows, made comparisons with WinMerge sometimes difficult.

Often I just used the Visual Studio editor and compared it with other code opened in Wordpad because I could not get the corresponding codes to appear side by side in WinMerge. I did not think it would compile after two little changes, one missing ; at the end of a line, and one change of ei.KingDanger to ei.kingDanger.

At the moment the null move part of search() is still like this, there are no changes I think from what I had posted here:

Code: Select all


     // Null move dynamic reduction based on depth
     int R = 3 + (depth >= 5 * OnePly ? depth / 8 : 0);

      if (refinedValue - beta > PawnValueMidgame)
         R++;

     pos.do_null_move(st);

     nullValue = -search(pos, ss, -(beta-1), depth-R*OnePly, ply+1, false, threadID);

     pos.undo_null_move();

     if (nullValue >= beta)
     {
         // Do not return unproven mate scores
         if (nullValue >= value_mate_in(PLY_MAX))
             nullValue = beta;
			
         // Do zugzwang verification search for high depths, don't store in TT
         // if search was stopped.
			if (depth >= 6 * OnePly)
			{
				Depth verificationDepth = depth - (ttMove == MOVE_NONE ?  3*OnePly : 5*OnePly);
				Value verificationValue = search(pos, ss, beta, verificationDepth, ply, false, threadID);
				if (verificationValue >= beta)
				{
					nullValue = verificationValue;
					if (!AbortSearch && !TM.thread_should_stop(threadID))
					{
						assert(value_to_tt(nullValue, ply) == nullValue);
						TT.store(posKey, nullValue, VALUE_TYPE_NS_LO, verificationDepth, ss[ply].pv[ply]);
					}
					return nullValue;
				}
				if (ttMove == MOVE_NONE)
				{
					ttMove = ss[ply].pv[ply];
					tte = TT.retrieve(pos.get_key());
					ss[ply].eval = value_from_tt(tte->value(), ply);

					refinedValue = refine_eval(tte, ss[ply].eval, ply); // Enhance accuracy with TT value if possible
					update_gains(pos, ss[ply - 1].currentMove, ss[ply - 1].eval, ss[ply].eval);
				}
         }
			else
			{
				return nullValue;
			}
     } else {
            // The null move failed low, which means that we may be faced with
            // some kind of threat.
Just for documentation purposes, it is not a suggestion or anything. It compiles and runs but that is all I can say about it because it is just the first functional build 8-) I think now I first should try to get Dann's "smooth reduction" working again.

The use of a deeper verification search if there is no ttMove, for IID purposes, works, but I'm not sure it is any good, that was also a change just copied from Rainbow Serpent 1.6.3s(dc) that was not well tested. I may throw it out again but for some of the changes I want to have a good ttMove/ttValue also for depths smaller than the depth at which you start exclusion searches. That is really the only small benefit I expect from doing verification searches deeper if there is no ttMove.

The slightly more interesting modifications in search I have not really posted about, if I manage to get them working again it would first need testing if it still works well with the Stockfish 1.7.1 search. Eval is I think more forgiving for changes and not much has changed there in Stockfish 1.7.1 itself.

I expect Rybka 4 to make a sizable jump soon, and then I think Stockfish will have a new target to focus on at least for the rating lists. For Rainbow Serpent I would rather not pay too much attention to results in engine-engine matches or any elo-results, and focus more on the analysis purposes. But first try to see if I can get some of the Rainbow Serpent 1.6.3s(dc) search modifications working again, with all of your changes Marco 8-) I thought you had said you had totally no time for Stockfish at the moment so 1.7.1 was a real shocker :)

See you guys later!
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

Post Reply