Author: Tord Romstad
Date: 08:45:07 10/12/03
Go up one level in this thread
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? And doesn't this cause too many tactical mistakes? >>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.