Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Checks in the Qsearch

Author: Christophe Theron

Date: 17:26:44 07/01/02

Go up one level in this thread


On July 01, 2002 at 12:21:09, Keith Evans wrote:

>On June 30, 2002 at 23:59:59, Christophe Theron wrote:
>
>>On June 30, 2002 at 12:28:32, Robert Hyatt wrote:
>>
>>>On June 29, 2002 at 14:18:53, Christophe Theron wrote:
>>>
>>>>On June 28, 2002 at 17:54:56, Keith Evans wrote:
>>>>
>>>>>On June 28, 2002 at 16:33:10, Scott Gasch wrote:
>>>>>
>>>>>>Another idea that I read from was that generating non-capturing checks in the
>>>>>>qsearch against a side that has had a chance to stand pat already is a waste.  I
>>>>>>really don't understand this idea and disagree with it.  Imagine black has had
>>>>>>an oppertunity to stand pat but instead plays RxN (N appears hung).  Well this
>>>>>>looks really good unless white then generates Qd4+ forking blacks R and K and
>>>>>>winning the R.  If you neglect to generate checks on a side who has already had
>>>>>>the chance to stand pat you let him get away with RxN and like it.  If the only
>>>>>>reason to add checks to the qsearch is to find mates then I agree -- checking
>>>>>>after a side could stand pat is wasted.  But if the goal is to improve tactical
>>>>>>play then I think this idea is not sound.
>>>>>
>>>>>I'll be very interested to see what responses this generates. Hsu took the time
>>>>>to design and implement special logic to help generate checking and check
>>>>>evasion moves in Deep Blue which I assume was used in qsearch. This was not a
>>>>>trivial undertaking - it adds both additional logic and additional interconnect.
>>>>>He probably had a good reason for doing it, since he could have used that time
>>>>>for something else like implementing a small hash table.
>>>>
>>>>
>>>>
>>>>And maybe he had no good reason to do it.
>>>>
>>>>As far as I know there are many amateur programmers here that have spent much
>>>>more time in trying and validating ideas (not even speaking of the commercial
>>>>programmers) than Hsu.
>>>>
>>>>I think Hsu and his team have done a great job in implementing a chess program
>>>>in a chip.
>>>>
>>>>However I think taking him and his team as a reference in chess programming is a
>>>>big mistake.
>>>>
>>>>As I have said, I think there are many chess programmers here who are much more
>>>>skilled than Hsu and his team in chess programming.
>>>>
>>>>
>>>>
>>>>    Christophe
>>>>
>>>>
>>>
>>>
>>>Hmmm.. I would _never_ make that statement.  Have you _ever_ talked with
>>>Hsu or Campbell?  I suspect not because if you had, you would not think
>>>them quite that incapable.
>>
>>
>>I did not say that they are incapable. They have done things I will never be
>>able to do.
>>
>>However I have read their description of the Deep genealogy (the document
>>published last year and describing their creatures in details, in particular
>>their evaluation function and search algorithms).
>>
>>I think it's probably as good as or even better than having a talk with them, or
>>else what is the purpose of their publication?
>
>I assume that you're referring to an unpublished version of the paper "Deep
>Blue" Artificial Intelligence 134 (2002) 57–83 (available from
>www.elsevier.com/locate/artint)



Yes.





>Do you have any opinion regarding the part related to checks in the qsearch?:
>
>"The main parameters of the hardware search are described below:
>...
>5. Number of “mating” checks allowed for each side in the quiescence search.
>A mating check is a checking move which allows zero escape squares for the king
>or any checking move which is a “contact” [15] check by the queen. This
>parameter is used to control the size of the quiescence search.
>6. Number of singular checking moves allowed in the quiescence search (king has
>one escape square, or queen or rook contact check, or any check given while the
>checked side has a hung 16 piece). This parameter is used to control the size of
>the quiescence search.
>...
>
>[15] A contact check is a checking move to a square immediately adjacent to the
>opposing king."



Yes I have an opinion.

This paragraph as well as many other things I have read in their document shows
that they had some ideas, but due to lack of time to develop and try them, they
end up with something only half baked. So it turns out to be not working and/or
just a waste of time.

The paragraph above can be interpreted in different ways, but all of them end up
uncovering an inefficiency somewhere:

1) (most probable) do they call any contact of a queen with the opponent king a
"mating check"? Even in the case where the king or any other piece can simply
recapture the queen? If yes, generating them is in average a waste of time
everywhere in the QSearch and the optimal number of mating checks for this case
is 0.

2) a contact of the queen and king is defined as a mating check only if the king
has no escape and the queen cannot be captured. In this case it is a checkmate
and if you can detect this in hardware there is no point in generating them.
Just return +MATE and you are done. The optimal number of QSearch moves (plies)
to apply this detection is +INFINITE (apply it everywhere in the QSearch).

When I read what has been put in the chips (and most of the time has not been
used), I can easily see that they had no idea about what would work and what
would not.

Any skilled chess programmer would have quickly known. That's what the job is
all about: generate ideas, test them, start again.

If they had invited a real chess programmer in the team, the last version of the
chips would have been much more efficient.

What this means is that Hsu and his team were at a very high, professional level
when it is about hardware design. They were at a very amateurish level on the
matter of chess search algorithms.



    Christophe



This page took 0.01 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.