Author: Tom Likens
Date: 13:30:02 03/02/03
Go up one level in this thread
On March 02, 2003 at 15:47:05, Robert Hyatt wrote: >On March 02, 2003 at 12:15:19, Tom Likens wrote: > >> >>I ran across an interesting bug the other day that I thought I'd share >>and also get some advice on. I hash the scores and moves that I get >>from the tablebases during a search. For a normal draw (i.e. a non- >>stalemate draw) I simply store any move that maintains the draw in both >>the hash table and the principal variation. >> >>The problem I ran into is that when a stalemate is encountered, there is >>no move to store. This has the potential to corrupt the hash table. >>Unfortunately, since the tablebase only returns a 0 for a draw, there is >>no easy way to differentiate between the two types of draws. I'm curious >>how other people handle this problem. I can think of a couple of >>solutions, but none that are completely satisfactory. >> >>1. Whenever a draw is returned from the tablebase verify that it is >> or is not a stalemate. If it is a stalemate, skip the storage step. >> This is accurate and works, but it's slow. > > >I don't understand the problem. You advance to ply N+1 after making a move >at ply N. You do a repetition check. If it returns "true" you have no move >to store, just a score although I don't store at this position since the >rep test is done first and there's no point. But, then you probe the egtb >tables, and if you get a hit, there is no best move either at this ply. You >just store the score, a best=0, and back up to the previous ply where there >_is_ a best move... > >Maybe you are doing something different??? Yes, slightly. I handle the repetition check exactly as you describe but I handle egtb hits a bit different. Since these are by definition "exact" scores I update the PV variation at this point by essentially enumerating through the moves using the following algorithm: Generate all the moves in the current position and score them using the tablebases. Stuff the best move into the principal variation (repeat until done). I limit this so that I don't run past the end of the PV. As a by-product, this also provides a move to store in the hash table, except in the case of a stalemate or actual mate, since both end the game. I could let the search handle this as you suggest but currently do it differently. In fact, I'll probably try your approach later today to see if I like the results. regards, --tom
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.