Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Junior-Crafty hardware user experiment - 19th and final game

Author: Robert Hyatt

Date: 07:27:05 12/24/03

Go up one level in this thread


On December 24, 2003 at 03:19:35, Uri Blass wrote:

>On December 23, 2003 at 22:57:28, Daniel Clausen wrote:
>
>>On December 23, 2003 at 21:44:07, Robert Hyatt wrote:
>>
>>[snip]
>>
>>>Look at Shaeffer's stuff on Sun Phoenix.  He had problems getting reasonable
>>>efficiency on a distributed search with an old 10mbit ethernet LAN, so he
>>>split the system into two parts, one that searched normally, one that did a
>>>fast tactics-only search.  And he reached the same conclusion.  What to do
>>>when they disagree.  Or when the positional search says "play X" and the
>>>tactical search says "X sucks".  :)
>>
>>I wouldn't play X. Seems obvious to me. :)
>>
>>On a more serious note: I would assume that the tactical and the positional
>>search wouldn't be normal searches, where we only get one best move and the
>>knowledge about all the other moves is limited to "being worse".
>>
>>
>>>I don't like the concept myself, but perhaps it can work.
>>
>>I like the concept, as it seems that that's often how humans play chess. (they
>>like some moves but have to verify whether they're also tactically sound)
>>Whether the concept is also applicable to computers is another question...
>>anyway, I think it's something worth to try, instead of "going where everybody
>>else has gone".
>>
>>Sargon
>
>I do not think that humans search some moves in parallel.
>They may use something more similiar to Rebel that evaluates every node when it
>is close to the root and does lazy evaluation when it searches deeper (in the
>qsearch)
>
>Based on discussion with Ed the lazy evaluation only means not considering stuff
>that was not relevant in previous plies when the full evaluation is used
>and everything that the full evaluation knows is going to be discovered if Rebel
>searchs deep enough.
>
>
>The disadvantage that I can see is that using hash tables become more
>problematic because the score may be dependent not only on the final position
>but also on the path.

It might be worse than that.  If your evaluation "mutates" as the search
goes deeper toward the horizon, then you have to somehow make sure that you
handle this correctly in the transposition table, which looks to be a real
problem.  IE you don't want to transplant pieces of the tree from one section
of the search space to another, if the depths are not equal, because the
"mutated evaluations" will be incorrect...

>
>I still believe that it is possible to use hash tables in a productive way in
>this case but the task is harder and the information in the hash should be not
>only the score but also which part of evaluation were used.

I don't see how that will help, since you still lack path information.



>
>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.