Author: Richard Pijl
Date: 01:01:37 04/07/05
Go up one level in this thread
On April 06, 2005 at 20:15:52, John Merlino wrote: >On April 06, 2005 at 19:51:24, Anthony Cozzie wrote: > >>On April 06, 2005 at 19:31:27, Walter Faxon wrote: >> >>>In a recent thread (http://www.talkchess.com/forums/1/message.html?419679), the >>>problem of on-line lookup of 6-man endgame tablebases was discussed. The >>>consensus was that for computer play, you could (maybe) load blocks of related >>>positions from near the root, not make individual requests for the value of >>>specific positions, since even fast net access is a snail compared to a good >>>hard disk. >>> >>>Either way, it takes a good block of time. To a much lesser degree, even >>>looking up the hash value for the current position can lose if its cache line >>>isn't already loaded. Main memory lookup can require hundreds of processor >>>cycles on modern hardware. (Probably a reason why Hyper-Threading(R) technology >>>works so well for computer chess. When one thread stalls the other might be >>>able to continue.) >>> >>>In between is the standard situation where a particular position in the tree has >>>multi-depth subsearches returning with widely varying scores and suggested >>>moves. You've reached a "hard" position. Or maybe before you've done any >>>searching on a position, you've somehow statically determined that it is "hard" >>>(like it will require a disk lookup). Either way, what should you do? >>> >>>My question is: Is it ever reasonable to just say "I'm going to leave the >>>evaluation of this position until later, if necessary." And continue the >>>search. It is possible and in many cases likely that the remaining search will >>>cut off at least some of the hard positions, and you will discover that you >>>never really needed to evaluate these in the first place. Maybe the search tree >>>could be marked so that when the "easy" search has been completed you can then >>>return to try to understand the remaining hard positions, in an order of how >>>they affect the remaining tree. >>> >>>Has anybody written code that addresses this? >>> >>>-- Walter >> >>Move ordering is very interesting, because you don't really want to search the >>best move first, you want to search the move that will provide a cutoff with the >>least amount of work. Unfortunately, this seems like a really hard problem . . >>. >> >>anthony > >The King always searches the best move from the previous depth first. Why would >you NOT want to do that? Wouldn't your biggest priority when reaching a new >depth be verifying what you have accomplished on the previous depth -- >especially if time is a consideration (and it usually is)? > >jm I'm pretty sure Anthony means innernodes (and more specifically cut nodes) here. This is something Humans do to a great extend. Just simplify the position when it is won. Maybe not the shortest road to a win, but one that takes limited effort to accomplish the goal. The amount of cut nodes (where you're only interested in a fast cutoff) is far greater than the amount of PV nodes where you would like to know the best move. Richard.
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.