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.