Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: How to handle EGTB stalemates

Author: Tom Likens

Date: 12:38:17 03/02/03

Go up one level in this thread


On March 02, 2003 at 13:24:44, Uri Blass 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 do not use tablebases but it is not slow.
>
>probing the tablebases is the real slow thing.
>If you decide to probe the tablebases inspite of that problem then the time to
>check if the position is stalemate is not significant.
>
>Uri

Hey Uri,

I actually implemented this, but wasn't satisfied with the results.  In
fact, it's what prompted my initial message.  I did experience a fairly
large slow down on some test positions that I tried before posting.
One position, went from 175k nodes/sec (which is OK since it was accessing
the tablebases like crazy) to around 65K (which isn't OK).

Of course, it could have been my sample size since I only tried it on
three positions, which isn't really representative of anything, but it
did seem consistent.

Related in a similar vein, are positions that are actual mate positions
(as opposed to positions that lead to mate in XX number of moves).
These positions also do not have a move to store in the hash table or PV.
Luckily, these easy to resolve, as long as you pay attention to the score
the tablebase provides, anything that is a mate now gets flagged.

regards,
--tom




This page took 0 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.