Author: scott farrell
Date: 01:17:28 08/30/03
Go up one level in this thread
On August 29, 2003 at 08:50:27, Mridul Muralidharan wrote: >Hi Scott, > > My comments inline. > > Please do note that , because of the way mess has been implemented , most of >these ideas may work for me - but maybe too expensive for others , or maybe >downright stupid/impossible for others to implement (just my disclaimer :) ) > > I'm currently still (!!) in the trying out ideas phase - so not much thought >to optimization , etc. Algorithmic improvements seem to give exponential >improvements as compared to the linear improvements given by code optimisation - >so that will come later :) > >I believe in sharing ideas (not necessarily code) , so here goes nothing ... > >Regards >Mridul > >On August 28, 2003 at 11:09:19, scott farrell wrote: > >>On August 28, 2003 at 10:55:20, Mridul Muralidharan wrote: >> >>>Hi, >>> >>>I use qsearch as a method of reaching quiet and calm positions, not as a method >>>to eliminate all captures. >>>Hence , I also try stuff like forking moves , threatening and checking moves , >>>etc - these may not be captures or promotions - but normal moves that can be >>>very threatening and dangerous. >> >>ONE VOTE FOR STAND QUIET FROM Mridul. >> >>I just score the pins/skewers etc in the eval, and it mostly throws out the >>position using alpha/beta instead. YMMV. >> > >I have eval for mobility , pinned , hung , skewers , etc - they definitely do >seem to improve the game play of mess - but like you said , ymmv for others :) > > >>I remember my engine before stand pat. It thought if there was a capture on the >>board it had to take it, and go through with the sequence. It played very funny >>chess for some time, and still managed to win lots, and played very very >>aggresively, making huge recapturing combinations on the board - very amusing. >>So if you dont put stand pat, how do you tell it that it doesnt have to take one >>of the moves in the move list, it can make no move instead (which when the full >>width search gets there, it can make a non capture move). >> > > >I expirimented with null move in qsearch which I got from ccc archive - some >adaptation of beal's algorithm - did not get much improvement out of it ... did >see degradation due to the higher times required to complete a search ply though >! >I still use standpat - cant seem to have a method of finding a way of working >around its limitations. >My idea is not to eliminate standpat - there is no way to do that , we will have >to return the standpat score at some depth in qsearch , but to reduce the >positions where standing pat score maynot be the right thing to do. >Examples would include : checks , zugwang positions , etc. Working on more ... > > >>> >>>Of late I have been noticing that , standpat though it give a nice speedup , can >>>be very bad for my search - atleast the quality of output it produces. >>>Even though I dont allow standpat in case like when in check , etc I still see >>>the pv ending in positions where , due to standpat , I get the score of a lousy >>>position. Maybe need to tune up eval more ?!! >> >>I am interested to hear this, maybe I will try to remove, and other ideas >>instead of stand pat. >> > >I have a seperate qsearch hashtable - 4 probe always replace. This gives me an >ok cutoff rate and also a good number of hashmoves to try first. >Especially since my qsearch is so expensive , this seems to pay off real well. > >Note my comments above about standpat - idea is not to eliminate them - no way >we will complete even ply 1 if we do that ! but to improve them so that they >dont return a score when they shouldnt. > > >>> >>>The observations you made w.r.t passed pawn was also observed by me - maybe like >>>you said , I need to identify more patterns for passed pawn eval. But the fact >>>remains , you cannot find all of them. So maybe it makes sense to keep these in >>>qsearch ? >>> >>>Extensions have always only blown up the search tree for me - skewed up search >>>tree , where a whole bunch of useless checking moves or captures keep getting >>>extended , while worthwhile lines miss out due to that one extra ply search that >> >>>they need to prove they are the best moves. So I rarely extend now , even >>>checking moves are rarely extended , unless they are "good". >> >>Every time I touch my check extensions, the strength goes down. I now just leave >>them at extend 1 full ply when in check, and 1 full ply for single escaping >>move. I am interested in how you discern 'useless checking' from good checking >>moves though? >> > >You can easily comeup with a easy set of positions where a check will be pretty >stupid to extend after static board analysis (without any search ofcourse !). > >Examples : > >1) Simple case : >[d] r1bqkb1r/pppp1ppp/2n2n2/4p3/3PP3/P4N2/1PP2PPP/RNBQKB1R b KQkq - 0 4 > >Trivial to see that Bb4+ is to be not extended. When i first saw your idea I was very excited. I tried that exact case, a check the does not capture, and can be captured by a pawn (I didnt look if the pawn is pinned against the king or other piece), and chompster's performance on WAC dropped significantly. I think chompster has so much futility pruning, and search reductions code, that if we extended something stupid, it gets pruned fairly quickly or reduced (the opposite of extension). > >2) Hung piece case : >[d] r1b1kb1r/1ppp1ppp/p1n2q2/4P3/P3n3/5N2/1PP1BPPP/RNBQK2R b KQkq - 0 7 > >Here , Bb4+ need not be extended too. > >And more cases which you can comeup quiet easily. >So these moves are not "good" moves - no point in extending them. >Actually this might look deceptively simple - had to work quiet a lot to get a >good set of positions , patterns and code to get all this to work well - and >ofcourse , there will be a list of cases where you will have to have special >cases to handle (like a capture that checks the king while a higher piece is >hung , etc , etc). > >So if a move is not good - then there has to be extraordinary circumstances >under which it will be extended. > >This "good" move code is not limited to checks - also applies to normal moves >(like making a move that leaves a piece hung , etc) , captures , etc. This gives >a great move ordering - at a performance loss. >This same code is reused in qsearch to find out the "good" captures to make and >the "good" threatening moves (checks , forks , etc) to make. > >My investigations are not yet complete - I continue to expiriment with the >threat analysis of a (non-cap/non-promo) move in qsearch , etc. > > >>> Recaptures - almost >>>never (depending on which version :) ) , have not tried singular extensions - >>>because I have not understood the implementation related concepts that well , >>>nor have I found much of a documentation of how it could be implemented. >> >>I put recaptures in/out/in/out also, but have them in now, found someone's idea >>somwhere, only recap on the same square, and only winning captures. This seemed >>really really strong. >> >>My extensions do go crazy sometimes. In the end game of blitz, sometimes I see >>it only gets 4 ply full width, and 25 ply in extensions, but it trounces the >>opposing computer with excellent pawn pushes and checks - and wins most of the >>time only searching 4-5 full width plies. >> > > Problem with recap that I found was that - almost an cap could degreade into a >recap - if it was a defended piece (like most positions in middle game) and if >your move ordering is good - then much higher probability of this ! So I found >that number of recap extensions was becoming intolerably high , while not giving >me much of a playing strength improvement - since i do handle so much in qsearch >anyway. So I ditched it will negligble impact (in very rare cases, i need depth >9 to see something i couldnot at depth 8 , etc). > Right now , I think I get quiet healthy search with very minimal extensions - >and all game losses that I have analysed mostly just a depth problem - not >something that an agressive extension scheme could have solved ! So I guess I >maybe on the right track :) > > >>>I tried a search through ccc archives - way too many threads - but none of them >>>had something that would not have adverse effects on search - tried a few ideas >>>and miserably failed. >> >>tried this also, blew up the search too much. >> >>>Rest of the extensions - i threw them out of the window. >>> >>>My $.02 >>> >>>Regards >>>Mridul
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.