Author: Vasik Rajlich
Date: 14:42:56 03/18/04
Go up one level in this thread
On March 18, 2004 at 16:43:02, Mridul Muralidharan wrote: >On March 18, 2004 at 16:11:46, Tord Romstad wrote: > >>Hi, Vasik and Mridul! >> >>On March 18, 2004 at 15:31:29, Mridul Muralidharan wrote: >> >>>On March 18, 2004 at 04:43:20, Vasik Rajlich wrote: >>>> >>>>Yeah, true, this is a big area. Actually secretly I hope to get rid of q-search >>>>completely and replace it with a static exchange evaluator. I don't trust a >>>>cheap q-search, and don't want an expensive one. >> >>I use a hybrid approach. Among many other things, my evaluation function >>tries to measure the tactical complexity of the position, by considering >>the number and values of hanging, pinned or overloaded pieces, and looking >>for possible forks. If the position is sufficiently simple, I replace >>the q-search with a SEE. If it is more complicated, I do a search. >>Depending on the position, I search only captures and promotions, or >>also promising checks, forks, and moves which bring attacked pieces to safe >>squares. >> Yes, I remember this. Thinking about it again, this must be the correct approach. However, I'd prefer to be making a decision between SEE and a bare-bones q-search. Forks in q-search seem really expensive, especially if you're going to try to handle them right and consider all the various defensive resources, etc. I'm happy to leave forks to the main search. >>There are still lots of things to improve in my qsearch, but with enough >>work I am convinced that it is possible to write a qsearch which is >>more reliable than a simplistic capture search, while at the same time >>searching fewer nodes. > Or: nearly as reliable as simplistic capture search, while searching far fewer nodes :-) >Hi Tord , > >Yes , and with care, you can prevent any sort of QSearch explosion. >It may not be trivial to do so , but since I managed to achieve this with >suficient sucess , I am sure anyone else can also do the same. >(And I do know of others who have this sort of thing). > If you feel up to it, I'd be interested to read more. Also, for justifying changes to q-search, it may be necessary to play games with a certain minimal time control - although I'm not sure what that should be. The proportion of the search which is q-search of course changes drastically depending on the time control. Also, testsuites for sure are totally inappropriate. A beefed-up q-search focuses the program towards tactical play, at the cost of positional play. >Something that I was unsucessful in my expiriments related to QSearch was >modifications of Beal's algorithmn for QSearch. >Unfortunately I never got this to work well. >From CCC archives , a very good description is available , which if sucessfully >implemented , may help in majorly minimising the possible node count explosion >in QSearch (other than by very complicated and possibly buggy (as in logically - >since we maynot consider all possible combination of patterns) by any other >approach.) > >> >>>>Perhaps you means "singular extensions" (yes I know it was 2:00 am :-)). >>> >>> >>> >>>Actually I meant selective extensions. >> >>(Description of idea snipped). >> >>If I understand your idea correctly, I do something similar, but less >>extreme. I extend all checks, but some checks are extended more than >>others. >> >>Tord > > > I did not understand the last part - >This could mean , you use either : >1) Allow multiple ply extension per position. >OR >2) Use fractional extensions. > >Which is the case ? > >I had a very interesting position , which Vincent helped me debug. >The search always used to hit MAX_SEARCH_PLY (which was 256 btw) for a position. >When we investigated more , we found that : >The only move available was a checking move - and this was getting extended. >(I used to extend checking moves - not check evasions : I have corrected this >bug hence) >Also , the null move search was returning a mate threat - due to which another >ply was getting extended. >In effect , I was extending 2 ply for this position. >The response is a king move , but the threat continues and the queen kept >running all around the board checking the opponent king (it was a perpetual >check case - but the number of combination of moves was too high for repetition >to kick in). >This was when I had just started - about 6 months or so later. >This was one of the first lessons I learned about how extensions can totally >screw up your search. >Ofcourse , by any standards , this was an amazingly crazy position - but still >it was quiet instructive to study it ! Yeah, every programmer with a <1 month old engine tries a few super-extension strategies. Then reality sets in :-) > >I do not use fractional extensions - this has the ability of making your search >path dependent. >And especially for singular extensions , this can be kill your tree (atleast for >me). > >Best Regards >Mridul
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.