Author: Bruce Moreland
Date: 15:26:59 07/26/01
Go up one level in this thread
On July 26, 2001 at 17:51:01, Artem Pyatakov wrote: >I was looking at the source codes of Gerbil and Crafty and noticed that they >handle the following problem differently: as part of the iterate/think loops >both programs try to force their program to search the PV nodes from the >previous iteration first, which makes sense, but the implementation of this is >very different. > >Gerbil just saves the PV into a separate array, while Crafty saves the PV into >the hash table. > >Now for my questions: > >1) What are the advantages/disadvantages of each of these implementations? Bob's way is easy to write and doesn't clutter up the search code. I wrote mine the way I did because I didn't want to have to mess with cases involving hash collisions and so forth. The search in my other program is more complicated and I'd be worried about losing the PV move, so I was perhaps a little too defensive with Gerbil. The bottom line is that I have an extra test per call to "Search". This isn't a big deal. >2) I don't understand how Gerbil solves the following problem, because from what >I see it only checks if the current move is equal to the PV move: what if the >current move matches the PV move AT THIS PLY, but what if the moves in the PLIES >BEFORE are different? When "Search" is called, the program checks to see if it has a PV move in its array for this ply. If so, it looks through the candidate move array, and if it finds a matching move (it will) it marks it with a sort key that causes it to be selected first. *Then* it nulls out this element in the PV array, so it won't recognize this as a valid condition if it sees it again. So it says, "If there's a move, find it and modify the sort key, then null out the move". The "if there's a move" test fails for every node except the dozen or so that might comprise the PV, so typically no work is done. I'm probably wasting significant time in another case, because I use this method when processing the "best" move, too. That iteration over the move list is probably significant time. >3) I don't understand how HashStorePV works - the code is kind of confusing for >a bitboards neophite like myself. In particular: what depth is it inserting the >moves as? With what score? This is another reason I didn't want to mess with this method, although I'm sure it is solvable. Anything that causes you not to cut off, but ensures that you'll try the "best" move first, would be fine. bruce >Thank you in advance for answering/clarifying these. > >Artem Pyatakov
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.