Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Qsearch Checks

Author: Uri Blass

Date: 08:19:19 09/07/04

Go up one level in this thread


On September 07, 2004 at 10:53:08, Stuart Cracraft wrote:

>On September 05, 2004 at 18:33:43, Bas Hamstra wrote:
>
>>On September 05, 2004 at 11:47:42, Stuart Cracraft wrote:
>>
>>>On September 04, 2004 at 18:30:36, Uri Blass wrote:
>>>
>>>>On September 04, 2004 at 18:20:49, Stuart Cracraft wrote:
>>>>
>>>>>On August 31, 2004 at 19:43:08, Uri Blass wrote:
>>>>>
>>>>>>On August 31, 2004 at 19:25:39, Stuart Cracraft wrote:
>>>>>>
>>>>>>>On August 30, 2004 at 15:53:13, Uri Blass wrote:
>>>>>>>
>>>>>>>>On August 30, 2004 at 15:34:22, Stuart Cracraft wrote:
>>>>>>>>
>>>>>>>>>On August 30, 2004 at 12:21:01, Uri Blass wrote:
>>>>>>>>>
>>>>>>>>>>On August 30, 2004 at 07:36:45, Volker Böhm wrote:
>>>>>>>>>>
>>>>>>>>>>>Hi Uri,
>>>>>>>>>>>
>>>>>>>>>>>do you allways check all evades in qsearch or only until a certain ply as for
>>>>>>>>>>>checking moves?
>>>>>>>>>>>
>>>>>>>>>>>Greetings Volker
>>>>>>>>>>
>>>>>>>>>>only until a certain ply but that ply is late.
>>>>>>>>>>I also do not check all captures and do it only until a certain ply.
>>>>>>>>>>
>>>>>>>>>>I practically have 2 functions of qsearch
>>>>>>>>>>int Quies(int alpha, int beta,int depth)
>>>>>>>>>>
>>>>>>>>>>int quiesmall(int alpha,int beta,int depth)
>>>>>>>>>>
>>>>>>>>>>Quies search checks and captures and when the depth is small enough Quies calls
>>>>>>>>>>quiesmall (quiesmall does not make checking moves that are not captures but it
>>>>>>>>>>calculate all replies to check unless the remaining depth is small enough and
>>>>>>>>>>when the remaining depth is 0 even captures are not tried.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Quies usually starts with depth=7 when depth=5 I call quiesmall and when
>>>>>>>>>>depth<=2 I do not generate replies to check and when depth=0 I do not make more
>>>>>>>>>>captures and retrun static evaluation+pawn with the idea that the side to move
>>>>>>>>>>may earn something by a capture but I do not know how much.
>>>>>>>>>>
>>>>>>>>>>It may be better to use static exchange evaluator but it is not very important
>>>>>>>>>>and most qsearch do not get to the place when depth=0 or the result of the
>>>>>>>>>>evaluation when depth=0 is not important for the final score.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>Uri
>>>>>>>>>
>>>>>>>>>So for all the trouble you have gone to to do all of the above, can you
>>>>>>>>>point at specific measurable achievements you have gained from it?
>>>>>>>>>
>>>>>>>>>Stuart
>>>>>>>>
>>>>>>>>I know that checks in the first plies of the qsearch improved the strength of
>>>>>>>>movei(the improvement was obvious in test suites and I believe that it also
>>>>>>>>helped in games but I did not play enough games to test it)
>>>>>>>>
>>>>>>>>I remember that a buggy implementation that could return wrong mate scores did
>>>>>>>>not change much the strength in games and I later fixed bugs.
>>>>>>>>
>>>>>>>>I think that the main improvement was that after adding checks in the qsearch I
>>>>>>>>changed null move with R=2 to null move with R=3 and R=3 was obviously better
>>>>>>>>with checks in the qsearch(I did not check without them but I read or got the
>>>>>>>>impression that other programs found that R=3 is better with checks in the
>>>>>>>>qsearch when R=2 or E=2/3 is better without them).
>>>>>>>>
>>>>>>>>limiting the qsearch was always part of movei because I did not want the search
>>>>>>>>to explode in Leonid'a positions when both sides have many queens.
>>>>>>>>
>>>>>>>>Movei has problems to go deep in Leonid's position but it has no problem of
>>>>>>>>needing an hour to find mate in 1 that happened to Fritz in one similiar
>>>>>>>>position that was discussed here(Leonid usually gave harder problems than mate
>>>>>>>>in 1).
>>>>>>>>
>>>>>>>>Uri
>>>>>>>>
>>>>>>>>Uri
>>>>>>>
>>>>>>>Uri,
>>>>>>>
>>>>>>>For short searches of 1 second on my box, I've found adaptive null move
>>>>>>>with varying R to give better results than verified null move with R=3.
>>>>>>
>>>>>>Note that I use verified null move pruning only in the endgame and in the
>>>>>>middlegame I use null move pruning with no verification.
>>>>>>
>>>>>>I did not test a lot of possibilities there and I only know that R=3 is
>>>>>>significantly better than R=2 and I also read that people who do checks in the
>>>>>>qsearch tend to prefer R=3(you do not do checks in the qsearch and I mean not to
>>>>>>replies to check).
>>>>>
>>>>>Uri,
>>>>>
>>>>>My program has this in relation to checks, all conditionally compilable:
>>>>>
>>>>>  1) all checks-evasions in quiescence, unlimited occurrences
>>>>>  2) all checks-evasions in main search, unlimited occurrences
>>>>>  3) all checking-moves in quiescence, at the first ply of quiescence
>>>>>
>>>>>These are the three extensions. Only #1 and #2 have proved useful.
>>>>>
>>>>>Stuart
>>>>
>>>>If your qsearch can call the main search then it is clear that 3 is not useful
>>>>because your search will explode by the following sequence:
>>>>
>>>>1.Qsearch checking move first ply
>>>>2.main search escape from check.
>>>>3.Qsearch checking move first ply because it is a new qsearch.
>>>>4.main search escape from check.
>>>>...
>>>>
>>>>If you want to use checks in the first ply of the qsearch then the qsearch
>>>>should never call the main search.
>>>>
>>>>Uri
>>>
>>>Uri,
>>>
>>>I should try tinkering with a qsearch that, if in check upon entry, simply
>>>generates check avoidance moves internally.
>>>
>>>Thanks,
>>>
>>>Stuart
>>
>>Hi Stuart,
>>
>>Yes, only then will you see the merits, I think... And you *will* crack Wac141
>>(and alike).
>>
>>
>>Bas.
>
>No such luck -- the quiescence slowed down considerably since it
>used itself to resolve ply-1 (of quiescence) checks instead of
>calling off to main search which uses extensions, null move, etc.
>to resolve.
>
>Also, the addition of checking moves terribly slows down my quiescence
>since for every legal move, not just captures, in the case of ply-1
>(of quiescence) I have to make the move, check if the side-to-move is
>now in check and if not or if not a capture/promotion/check-evasion
>then unmakemove and continue with next move in list.

I do not do it in that way.
In most cases it is easy to detect that a move is not check based on the
direction to the king of the from and to square.

I think that the best thing is to do like smirf and have a legal move generator
that detects checking moves and mating moves but even only detecting checks is
not an easy task and today I do not do it and simply loop on the list of legal
moves to find checks.

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.