Author: Stuart Cracraft
Date: 08:47:42 09/05/04
Go up one level in this thread
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
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.