Author: Mridul Muralidharan
Date: 05:50:27 08/29/03
Go up one level in this thread
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. 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.