Author: Stuart Cracraft
Date: 15:41:58 10/05/04
Go up one level in this thread
On October 04, 2004 at 20:23:27, Don Beal wrote: >Hmmm. It's very helpful to post the actual code. >My time is limited though. No problem -- you've made good comments and de-lurked and everyone enjoys that. The bet was to decrease the WAC #141 problem down to <= 10 seconds without turning off the null move as one claimant had done. Although I am now at 49 seconds for WAC 141 solution with null move enabled and not limited compared to the earlier 95 seconds, the <= 10 bet is still open. I'll hereby double the bet to $100 to the first person who helps me achieve it directly. > >My advice remains that the best next step would be to >get a reliable cost-effective qsearch going, so I'll >offer a few comments on your code for that, in case >that helps you. > >(1) >a bug: if you don't define SEE, you have the "usesee" >local variable uninitialised which will cause bad things. >However, I assume you are testing with SEE defined at present. Indeed, I am. SEE has been a permanent part of the program since the main part of my SEE, not including the attack/defender finder which feeds it, was given to me by a board member, and improved my results. My usesee variable was poorly named as it didn't span the presence of the conditional on SEE very well and was used outside of it as well. Bad and bug. I've moved it outside and renamed it "capture". The idea is, is the move a capture? If so, search it first time through only. Second time is for checking moves. That latter part is not enabled as it causes my quiescence to blow up / slow down and impacts my WAC results severely. >(2) >another possible bug, or may be just duplication and >waste of execution time: You have a comment "// First time only" >after the line "ifdef SEE". But I see nothing in the the code >to prevent the execution stream going though this >point on the second pass. Poor documentation in this case and noted prior to your post. Thanks for the confirm. >(3) >if you define QCXX (checks at ply 1 of qsearch), you >call genmv which I assume generates all moves. Then >the pass-1 moveloop appears to call quiesce on them >all (except any which are illegal because the leave >the moving side's king in check): > if (!incheckopp(bd)) > if ((timethru == 1 && usesee) > ... > value = -quiesce(bd,ply+1,-beta,-alpha,mvs,2,qdepth+1); >So this is essentially looking at all moves, not just >checks. It's more like another ply of full width search >than a capture list augmented by checks, and hence is doing >more work than is recommended for the qsearch. No matter what I do, my qdepth == 0 of genmv() for captures and check-giving blows me up. I've doublechecked it quite a few times to ensure it wasn't all moves being investigated at qdepth == 0. Not sure why it blows me up. But it does. >(4) >In general, the overall implementation seems to be too slow for >good performance. I agree with robust and easy-to-understand >code (assuming these are achieved!) at the expense of some speed, >but I think that, considered as an implementation of the kind >of qsearch I recommended in my last post, and considering that >your eval is currently only pcsq, you are running several times >slower than an efficient implemention. >Some things that will slow you down: testing for incheck >everywhere in qsearch, testing for repetitions everywhere, I have to do incheck tests to ensure moves are legal. >(repetition is only possible at root, and down a check-evade >sequence), doing string handling in qsearch. Well, I do want to detect draws in the tree. Draws are possible by agreement and do not require check sequences. >You might be limited by your SEE, but with a fast SEE in place, >I think a fast implementation could run several times faster >than your current one. > It is not bad but with bitboard attack implementation with incremental updating between moves, I think the program would do better. >I think inproving the qsearch cost-effectiveness is beneficial >whatever you use your program for. If that isn't helpful, >here is a final suggestion: I do like the three-tier qsearch you posted. I've printed it out and keep it in a cupboard with all my printed computer chess materials including most of the ICCA. > >Although I haven't had time to study your main search, there is >another lever you can add to your control panel. Replace: > // test for null move prune > value = -search(bd,sdepth-1-reduction,ply,-beta,-beta+1, > mvstr,SAVETOP,verify,REDUCENOTOK,checked); >by this: > // test for null move prune > value = -search(bd,sdepth-1-reduction,ply,-beta,-beta+1, > mvstr,SAVETOP,verify,REDUCENOTOK,checked) + WACBOOST; >where WACBOOST is a bias that increases tactical prunes. > >Hold the search time constant, so that more prunes allow >deeper search, and try values between zero and a half-pawn, >for example a quarter-pawn, to see if that improves WAC score. See later post for followup.
This page took 0.01 seconds to execute
Last modified: Thu, 07 Jul 11 08:48:38 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.