Fix a bug created by Aspiration Windows->Massive ELO loss

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

brtzsnr
Posts: 433
Joined: Fri Jan 16, 2015 4:02 pm

Re: Fix a bug created by Aspiration Windows->Massive ELO

Post by brtzsnr »

Edsel Apostol wrote:Don't retrieve and store hash table entries in the root (ply=0). It doesn't make sense. It will only return immediately after a re-search. For example, you have alpha = -100, beta = 100, you have returned a score of 150, you now do a research of the same depth with a wider window of lets say alpha = -100, beta = 200, now when you probe the hash table it will return immediately with a score of 150, without doing any re-search at all. What you can do is to retain the best move of the last iteration, and use that as the first move to be searched in succeeding iterations and re-search.
It's not correct to use a failhigh/lowerbound score (alpha = -100, beta = 100, score = 150) as an exact score (alpha = -100, beta = 200, score = 150). Using hash at root is fine, provided you handle the bounds correctly.

FWIW, in zurichess I do this:

Code: Select all

	if entry.kind != noEntry && depth <= int32&#40;entry.depth&#41; &#123;
		score &#58;= int32&#40;entry.score&#41;
		if entry.kind == exact &#123;
			// Simply return if the score is exact.
			// Update principal variation table if possible.
			if &#945; < score && score < &#946; &#123;
				eng.pvTable.Put&#40;pos, hash&#41;
			&#125;
			return score
		&#125;
		if entry.kind == failedLow && score <= &#945; &#123;
			// Previously the move failed low so the actual score is at most
			// entry.score. If that's lower than &#945; this will also fail low.
			return score
		&#125;
		if entry.kind == failedHigh && score >= &#946; &#123;
			// Previously the move failed high so the actual score is at least
			// entry.score. If that's higher than &#946; this will also fail high.
			return score
		&#125;
	&#125;
syzygy
Posts: 5566
Joined: Tue Feb 28, 2012 11:56 pm

Re: Fix a bug created by Aspiration Windows->Massive ELO

Post by syzygy »

Evert wrote:The advantage of returning a draw-score is that it at least has some rule-backing in that a third repetition is a draw (rather: can be claimed as such). Even without that, you can argue that it's the best thing to do, as follows.

If you find that your best option in the current position is to play a line that repeats the position, then the current position represents a (local) optimum in the evaluation for both sides, and neither side can make progress. If neither side can make progress towards winning the game, the game should be a draw (either by rule or agreement).
I fully agree. The main reason for scoring a first repetition within the search as a draw is not the three-fold repetition rule, but the fact that - apparently - neither side can make progress (should this branch be the "best" both can do).
kbhearn
Posts: 411
Joined: Thu Dec 30, 2010 4:48 am

Re: Fix a bug created by Aspiration Windows->Massive ELO

Post by kbhearn »

Evert wrote:
Uri Blass wrote: Not searching does not mean returning a draw score.

If you get a position that already was in the game but not twice then you can return for example previous score that you already had in the search or previous score that you already had in the search divided by 2(assuming the remaining depth is smaller then the real depth that you practically got in previous search).
I thought about that, but the issue is that if you have a repetition in the search, then you don't have a reliable score for this node yet, so it's not so obvious what the score to return should be.

The advantage of returning a draw-score is that it at least has some rule-backing in that a third repetition is a draw (rather: can be claimed as such). Even without that, you can argue that it's the best thing to do, as follows.

If you find that your best option in the current position is to play a line that repeats the position, then the current position represents a (local) optimum in the evaluation for both sides, and neither side can make progress. If neither side can make progress towards winning the game, the game should be a draw (either by rule or agreement).
If the remaining depth is higher than the depth that you had in previous search(can happen mainly in game with pondering when the opponent thought for a long time in the last move) then I think that it make sense to search and not stop in repetition.
It never makes sense to search the position again for a repetition in the search. Unless you extend by more than one ply several times, you're not going to have a higher remaining depth than you did the first time you encountered it, so you're just inviting horizon effects.
If the repetition is against the game history it's a different matter.
the simple answer here for the purposes of analysis is to hack together the game history such that only positions that occur twice in game history are treated as having happened at all. then the search can continue looking for a single repetition, and the user can be oblivious to the search not caring about needed a second repetition.

This would however still provide a potential detriment in gameplay as the engine in hard-to-progress positions wouldn't have as a guide 'i didn't find anything last time i was there, so it's probably drawn if i go back there and try again' so perhaps the pre-search hacked game history only makes sense if the engine's been told it's being used for analysis at the moment.
User avatar
hgm
Posts: 27810
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Fix a bug created by Aspiration Windows->Massive ELO

Post by hgm »

It would be sensible to remember which moves the engine had thought about, and which were forced by the user. When the engine returned to a position it visited once before through a series of moves it thought about, it is a good indication that it cannot see a way to achieve more than a draw. If some of the moves were forced by the user, there is nosuch guarantee, and it would be better to act like the position had not been visited at all.