| |
Main
Date: 30 Dec 2008 09:10:21
From:
Subject: Chess Programming: Quescent search
|
Most of the Chess programs I've examined handle quescence by
implementing a custom quescent search routine, oftentimes named
"Quesce".
I would think that a quescent search would be subject to all of the
same optimizations that occur in the general search such as alpha-beta
pruning, utilization of the transposition table, etc..., so my
question is why isn't quescent search just handled as a direct
extension of the main search (e.g. a position classified as unstable
is simply not considered a terminal position and therefore search
deeper). Why bother to implement a customized quescent search?
Any insights on this are appreciated.
-- Greg
|
|
| |
Date: 30 Dec 2008 12:13:56
From:
Subject: Re: Chess Programming: Quescent search
|
So I'm beginning to think that both approaches are valid and it's
basically a matter of choice based on a combination of code
organization and efficiency.
-- Greg
|
| |
Date: 30 Dec 2008 13:35:13
From: Guest
Subject: Re: Chess Programming: Quescent search
|
<[email protected] > wrote in message
news:6f94d82e-947a-4371-9237-9f5e896f1137@q30g2000prq.googlegroups.com...
> Most of the Chess programs I've examined handle quescence by
> implementing a custom quescent search routine, oftentimes named
> "Quesce".
>
> I would think that a quescent search would be subject to all of the
> same optimizations that occur in the general search such as alpha-beta
> pruning, utilization of the transposition table, etc..., so my
Right. Although you need to be careful about putting quiescent search
results into the trans table.
> question is why isn't quescent search just handled as a direct
> extension of the main search (e.g. a position classified as unstable
> is simply not considered a terminal position and therefore search
> deeper). Why bother to implement a customized quescent search?
It often is combined.
Most of the differences are hidden elsewhere (in the GenNextMove() function)
or with a flag saying whether its the normal search or some part of the
quienscent search.
Such as:
If (InQSearch == TRUE) then GenerateQMoves();
else GenerateAllMoves();
But many people prefer to have it seperate because they do things
differently enough from the regular search that it looks cleaner and is more
easily maintained when seperate.
There is no fundamental reason you can't combine them. And many people do
precisely that.
But many just prefer to keep them seperate for better organization, etc.
The more complex you do your Qsearch, the more extensions etc., the more
convenient it is to have it seperate.
> Any insights on this are appreciated.
>
> -- Greg
----== Posted via Pronews.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.pronews.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= - Total Privacy via Encryption =---
|
| |
Date: 30 Dec 2008 10:52:47
From:
Subject: Re: Chess Programming: Quescent search
|
On Dec 30, 1:16=A0pm, Simon Krahnke <[email protected] > wrote:
> You usually have optimizations beyond alpha-beta and transposition-
> tables. Theses are usually not shared across normal search and quiescent
> search.
>
> And the fundamental difference of course is, you don't search all the
> moves. Accordingly they are sorted differently.
>
> Plus some convergence tricks like going back to normal search for one
> ply when you are in check.
>
> That's so many depth=3D=3D0 tests (one for the recursion!) that you
> are usually better off giving it its own function.
>
> mfg, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 simon .... l
I was also thinking that the search could be in "quescent mode" when
it is searching the extra plys and thus could do additional things
such as only generate captures. I think you're saying that's
possible, but generally inefficient. I wonder if any existing
programs do it this way.
-- Greg
|
| |
Date: 30 Dec 2008 19:16:35
From: Simon Krahnke
Subject: Re: Chess Programming: Quescent search
|
* <[email protected] > (18:10) schrieb:
> Most of the Chess programs I've examined handle quescence by
> implementing a custom quescent search routine, oftentimes named
> "Quesce".
>
> I would think that a quescent search would be subject to all of the
> same optimizations that occur in the general search such as alpha-beta
> pruning, utilization of the transposition table, etc..., so my
> question is why isn't quescent search just handled as a direct
> extension of the main search (e.g. a position classified as unstable
> is simply not considered a terminal position and therefore search
> deeper). Why bother to implement a customized quescent search?
You usually have optimizations beyond alpha-beta and transposition-
tables. Theses are usually not shared across normal search and quiescent
search.
And the fundamental difference of course is, you don't search all the
moves. Accordingly they are sorted differently.
Plus some convergence tricks like going back to normal search for one
ply when you are in check.
That's so many depth==0 tests (one for the recursion!) that you
are usually better off giving it its own function.
mfg, simon .... l
|
|
