Any ideas what's going on?

[mambofish]

Here's the code I use to check for cutoffs from the transposition table before generating moves:

Code: Select all

		// 4. try to get a TT cutoff
		Position p = TranspositionTable.get(board.hash);
		if (p != null && p.depth() > depth) {
			if (p.isExact()) {
				return p.score;
			}
			if (p.failedHigh()) {
				if (p.score >= beta) return beta;
			}
			if (p.failedLow()) {
				if &#40;p.score <= alpha&#41; return alpha;
				do_null = false;
			&#125;
		&#125;

Now I would think that the depth comparison should be >= not > , otherwise I don't cutoff any positions at the current depth. However, if I do this, my program doesn't find some tactical wins as quickly.

Has anybody got any idea why this would be?

Regards
Vince

[/code]

[Zlaire]

I have >= in my code. But the rest of your code looks right, the problem probably lies somewhere else in your code.

Took me a month of trials and errors to get it all right, and I haven't touched it since just to be sure.

[Ron Murawski]

Here's the code I use to check for cutoffs from the transposition table before generating moves:

Code: Select all

		// 4. try to get a TT cutoff
		Position p = TranspositionTable.get(board.hash);
		if (p != null && p.depth() > depth) {
			if (p.isExact()) {
				return p.score;
			}
			if (p.failedHigh()) {
				if (p.score >= beta) return beta;
			}
			if (p.failedLow()) {
				if &#40;p.score <= alpha&#41; return alpha;
				do_null = false;
			&#125;
		&#125;

Now I would think that the depth comparison should be >= not > , otherwise I don't cutoff any positions at the current depth. However, if I do this, my program doesn't find some tactical wins as quickly.

Has anybody got any idea why this would be?

Regards
Vince

[/code]

Hi Vince,

try this:

Code: Select all

		// 4. try to get a TT cutoff
		Position p = TranspositionTable.get(board.hash);
		if (p != null && p.depth != 0 && p.depth() >= depth) {
		{
			//...try doing TT cutoff
		}

At depth == 0 you don't always have a trustworthy value to return! (But at depth == 0 it would be okay to return if the score was a checkmate in favor of the side to move.)

Ron

[mambofish]

Thanks for the suggestions, they helped me find the problem - extensions!

When there is an extension, the current depth is incremented and a new search invoked. When that search returned, any cutoff value was being stored at the extended depth. By changing this so that the non-extended depth is stored in the ttable, the >= comparison works, and my ecm/sac/wac test suites don't get lower scores than when just using >.

I still think this is not quite right however. When you think about it, modifying the current depth for an extension is kind of a "trick" to get the search to go deeper than it otherwise would. If I had two plies, both extended, my current scheme would be incorrect below the second extended search. What I think I really want to use is the "nominal" search depth (i.e. as if no extensions had occurred anywhere in the tree).

All of this probably has to be understood in the context of my t-table implementation which is slightly unusual in that I happily admit qsearch results. (Not only that, but I do not force depth=0 at horizon - I allow depth to go as negative as the "below horizon" part of the search takes it. So, all values at depth > 0 in the ttable are above the horizon and all results <= 0 are below it.

I do this partly because I don't have separate routines for main search and q-search but mainly because I have come to the conclusion that putting qsearch values in the ttable should not cause a problem. After all, the "horizon" is just an arbitrary depth where I am effectively saying lets start truncating the search if we can. So to handle this concept, my move generation routine has 2 pieces of information. 1) am i in check and 2) am i above the horizon. If either is true, all moves are generated, otherwise, just the captures. (not currently promotions or checks). I believe that this means that even below the horizon I can be pretty confident that any value in the ttable is accurate, and empirically at least, this seems to be the case.

Now you can all tell me why this is wrong

Regards
Vince