Author: Uri Blass
Date: 13:26:24 03/02/03
Go up one level in this thread
On March 02, 2003 at 15:38:17, Tom Likens wrote: >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). Hello Tom, I can say that something is clearly wrong with your speed without discussing the question if you need to evaluate if a tablebase position is stalemate(I did not think about it because I still did not think of implementiing tablebases and I also do not understand why you need it only for tablebases positions). Movei does not probe tablebases but it detects stalemate and checkmates in every position that it evaluates and is not so slow because of it. The main factors that do movei slower are: 1) counting legal moves in every position in the tree(latest movei save sometime by pruning some positions before counting legal moves). 2)generating all the check moves in the first plies of the qsearch(movei still use primitive function that generate all the legal moves and checking for everyone of them if it is a check). Inspite of these problems movei search clearly more than 200K nodes per second in endgames on a relatively slow hardware p850. Based on what you tell me it seems that you cannot even search 100Knodes per second if you only need to evaluate for every position in the tree if it is a stalemate. It means that something in your function to detect stalemate is wrong. The simplest way to detect if a position is astalemate is to generate the list of legal moves and stop if you find at least one(movei does more than it and generate the full list. I do not understand how this process can be so slow. I think that you should think how to improve it because information if the position is stalemate or checkmate can be productive at every node of the tree and not only at tablebases position. Uri
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.