TT in endgame

[BitSet]

Hi,
Looks like transposition table causes serious problem in edgame (at least in my case). Recently my engine has seven pawns advantage over TSCP and the game ended up in a draw because of threefold repetition. I used to check if the best successor from TT will cause draw by repetition in current situation but that's not the case. Because of the fact that in endgame TT successor is often returned at root node and no further analysis is performed, my engine doesn't spot that returned move will alow opponent reply that will actually cause draw by threefold repetition. So I decided not to use TT when game state that will be looked up has already occured in the game or current variation (I've noticed that if state that has already occured in the game is looked up in TT it is common that game ends up in a draw). I don't know if it's good solution. Maybe You have some experience in using TT in the endgame.

[H.G.Muller]

TT are most useful in the end-game, and I think you will cripple your engine by not using it there. Perhaps better would be to suppress TT cutoffs in the first 3 or 4 ply, so that you are sure the repetition-detection code will be executed there. Then you will never stumbleinto a repetition blindly.

[BitSet]

Seems to be good idea but I'm not sure if it really is for engine which usually searches to the deph between 7 and 12.

[H.G.Muller]

Why not? Even at 7 ply less than 1% of your tree nodes has d<4.

[BitSet]

That's right and the conclusion is if TT cutoff occurs close to the root node then benefits are greater because more nodes are skipped.

I allow TT query only if game state didn't actually occured (or may have occured - current variation) in the game. But with Your idea it can be improved to allow lookup also when distance between current node and root node is greater than 3 plies.

[H.G.Muller]

That's right and the conclusion is if TT cutoff occurs close to the root node then benefits are greater because more nodes are skipped.

That is not true at all. If an entry at ply level 2 would have gotten a hit for a remaining depth (= draft) of 5, it means that the daughter nodes (with draft 4) of the 5-ply search that created that entry are probably also still in the table, as are the grand-daughter nodes of draft 3. So if you ignore the hits at level 2 and 3, you will get all the hits at level3. Effectively you would only be doing a 2-ply search from level 2 with hash-cut leaf nodes at ply=4, so taking the d=5 hit will hardly have saved you any time at all.

[crystalclear]

I am looking for a thread to resurrect discussion about transposition tables.

I have just found this one and the problem described reminds me of something I discovered recently called Graph History Interaction :-
http://webdocs.cs.ualberta.ca/~mmueller/ps/aaai-ghi.pdf

The article I thought was of the most interest was this one, as it appeardd to describe a way to code elegantly and effectively around the problem.
http://wiki.cs.pdx.edu/wurzburg2009/nfp ... ll-ghi.pdf

But I am wondering if I can pick people's brains a little on the general subject of transposition tables, and I'll put that in a separate posting.