Stockfish 1.7.1 update available

[mcostalba]

I'm trying my idea of only storing the verification search results

This could be interesting. Thanks Eelco, I will test it

[mcostalba]

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.

[Eelco de Groot]

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