Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Bean Counter

Author: Dann Corbit

Date: 12:56:34 09/30/99

Go up one level in this thread


On September 30, 1999 at 09:19:57, Robert Hyatt wrote:
[snip]
>There are a couple of problems...  if you aren't going to use alpha/beta, and
>decide to try some sort of alternative like best first, then this kind of search
>might make sense.  If you do stick with alpha/beta, the order in which you
>search things is critical, and which things you search first to establish an
>alpha/beta bound is also critical.
>
>Others have tried things like a normal engine with a cluster of machines working
>together, and also a stripped-down engine with a cluster of machines working to
>search a couple of extra plies tactically (Schaeffer did this in Phoenix,
>calling the stripped-down program 'minix').
This is fairly close to what I have in mind.  Imagine that for the root node, I
have a normal program working in the normal way (imagine crafty or phalanx or
whatever buzzing away).  Now, for each subsequent position from the current, I
have another instance of the same program analyzing.  After a configurable
period called 'heartbeat' they check back with a synchronization object and
report their findings.  Those that look futile will abandon their tasks and pick
up analyzing where it is needed (likely in subsequent positions from those
positions that do look favorable.)  The main thread (which stays put) will also
have access to this "speculation" data.  I see two benefits.  First, positions
may look very bad at first and so get pruned.  However, further exploration
would reveal a benefit.  I see this a lot in EPD test positions that chess
engines do not solve.  When posed the problem, they find the wrong answer.
However, once you put them on the right answer position, they see the benefit
almost immediately, since they are now *forced* to look more closely.  Second,
since chess is exponential, extrapolation of higher plies becomes more and more
difficult.  However, most positions have only 3 or 4 real candidate moves, and
so by a method like I describe, these are the ones that will receive the
attention.  Since the chess engines are more or less independent, let's imagine
that each engine can calculate only 10 plies in the time allotted.  If I can get
one engine to find valuable results 4 plies down steam, I have really achieve 14
plies (though the last four are speculative).

>It is an interesting idea although for anything but the longest of time controls
>network lag/jitter/latency will be a huge issue...
I have no interest whatsoever in time controls of less than 40/2.  The program
would *really* come into its own analyzing correspondence chess positions
overnight.




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.