Author: Vincent Diepeveen
Date: 06:29:47 10/13/03
Go up one level in this thread
On October 13, 2003 at 08:56:05, Omid David Tabibi wrote: >On October 13, 2003 at 08:50:12, Vincent Diepeveen wrote: > >>On October 12, 2003 at 12:03:37, Omid David Tabibi wrote: >> >>>On October 12, 2003 at 11:45:07, Tord Romstad wrote: >>> >>>>On October 12, 2003 at 10:23:35, Omid David Tabibi wrote: >>>> >>>>>[D]6k1/5p2/3P2p1/7n/3QPP2/7q/r2N3P/6RK b - - 0 1 >>>>> >>>>>If you do checks everywhere in quiescence, you should see this immediately. >>>> >>>>If I did *all* checks everywhere in qsearch, I should see it instantly, yes. >>>>But as you >>>>remarked in the article at the beginning of this thread, this is too expensive. >>>>Beyond >>>>the first ply of qsearch, I have very strong restrictions about when and which >>>>checks >>>>to generate. >>>> >>>>>After 1...Rxd2 2.Qxd2 all the rest of the moves are checks until you detect draw >>>>>by threefold repetition (maybe you've turned off repetition detection in >>>>>quiescence? or your max extensions limit is too shallow...). HIARCS finds the >>>>>move at the first iteration! >>>> >>>>I do repetition detection in quiescence, and I have no max extension limit. >>>>Looking >>>>closer on the position in question, it does seem a bit strange that I need such >>>>a long >>>>time to find the solution. The combination is not very deep. Perhaps I have a >>>>bug >>>>somewhere -- it's worth a closer look. >>>> >>>>>Falcon doesn't manage to solve number 12 either. >>>> >>>>Number 12 is very hard. But even solving number 10 and 11 in less than a >>>>second >>>>is very impressive, IMHO. >>>> >>>>>>You must have a very inefficient way of generating checks, I think. >>>>> >>>>>That's true. Only recently I added checks in quiescence to the engine, and so >>>>>still haven't written a gen_checks() functions. However, the kind of attack >>>>>tables I use result in a very speedy generation of captures, which results in a >>>>>very optimized captures only quiescence. Adding checking moves will slow down >>>>>the engine considerably anyway, even if I write a good gen_checks()... >>>> >>>>I am not so sure about that. Most of what you write above applies to my engine, >>>>too. The attack tables are useful when generating checks, too. And of course >>>>you >>>>do not generate checks before you have generated and searched all captures and >>>>they all failed low. >>>> >>>>>One thing I have to mention is that in the normal version I never check for >>>>>check evasions in quiescence. If the side to move is in check and doesn't have >>>>>any legal non-losing capture, I just return eval(). That's another reason why >>>>>the normal quiescence is so fast. >>>> >>>>This sounds extremely dangerous to me -- doesn't this imply that you will not >>>>always detect mates in qsearch? >>> >>>No checkmate can possibly take place at the first ply of quiescence, since I do >>>the following in the main search: >>> >>>... >>>makemove(move); >>>if (other side is in check) >>> extension += 1; >>>call_depth = depth - 1 + extension; >>>if (call_depth > 0) >>> score = -search(..., call_depth); >>>else >>> score = -quiescence(...); >>>... >> >>isn't that very inefficient unless you extend moves that give a check instead of >>moves that get out of check. > >Sure. There is no difference. there are very big differences. > >> >>of course moves that get out of check, to extend them is always better which is >>easily provable even theoretically. >> >>>So if the other side is in check the depth will be extended instead of calling >>>quiescence. >>> >>>But within the quiescence no checkmate can be detected in the normal version. >>> >>> >>>>And doesn't this cause too many tactical mistakes? >>> >>>It to causes problems mainly in null-move pruning. Assume you are at depth = 3 >>>and use R = 2. Your calling depth is 3-2-1=0, i.e., you directly call quiescence >>>(after doing a null-move). Now it is the opponent's turn who checkmates you in >>>the first ply of quiescence. Using checks in quiescence the checkmate will be >>>detected, which will trigger a mate threat extension in the main search. >>>Otherwise (in the normal version) just eval() is returned and assuming it is >>>above beta we have a fail-high. All good and nice we are sure that our position >>>is good enough to justify a cutoff, while in fact we are mate in 1! >>> >>>That's the main reason why checks in the first ply of quiescence contribute so >>>much to tactical strength. >>> >>> >>>> >>>>>>It seems like checks in the qsearch is one of those things that works well in >>>>>>some >>>>>>programs, and not in others. Crafty, for instance, seems to do very well >>>>>>without >>>>>>any checks whatsoever, >>>>> >>>>>I wouldn't say so from a tactical point of view. Whenever the game turned >>>>>tactical, Crafty didn't have any chance against Falcon with checks in >>>>>quiescence. But Crafty did search deeper and played a better positional game. I >>>>>must also add that Falcon uses a huge number of different extensions (I think >>>>>only HIARCS has more extensions), and so maybe adding checks in quiescence on >>>>>top of them all isn't such a good idea... >>>> >>>>Very interesting. >>>> >>>>>>but for me the results without checks are clearly worse. >>>>>> >>>>>>Other ideas that I have never been able to make work are recapture extensions >>>>>>and >>>>>>all sorts of nullmove pruning except plain R=3 (R=2, R=2.5, adaptive pruning and >>>>>>verified >>>>>>nullmove pruning are all clearly worse for me). >>>>> >>>>>In Falcon I conducted all the experiments I conducted on Genesis for the paper >>>>>verified null-move pruning, and got the same results. Plain R=3 was too risky >>>>>neglecting many tactical shots. I now use a modified version of verified >>>>>null-move pruning. >>>>> >>>>>But maybe plain R=3 didn't work for me because I didn't have checks in >>>>>quiescence, and so it resulted in a very inaccurate search. The only program >>>>>I've heard which uses plain R=3 is DIEP, which does conduct checks everywhere in >>>>>quiescence. >>>> >>>>This is very possible. I have experimented with values of R below 3, and with a >>>>minimalistic qsearch without checks, but never in combination. Probably yet >>>>another thing I should try ... >>>> >>>>Tord
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.