Author: Landon Rabern
Date: 09:24:49 07/20/00
Go up one level in this thread
On July 20, 2000 at 08:15:17, Bas Hamstra wrote: >On July 19, 2000 at 14:51:17, Landon Rabern wrote: > >>On July 19, 2000 at 14:08:23, Andrew Dados wrote: >> >>>On July 19, 2000 at 14:00:16, Landon Rabern wrote: >>> >>>>On July 19, 2000 at 13:22:47, Andrew Dados wrote: >>>> >>>>>On July 19, 2000 at 12:03:10, Landon Rabern wrote: >>>>> >>>>>>I have been discarding all captures where attackervalue>DefenderValue in my >>>>>>q-search which speeds it up significantly, but I know that it is throwing away >>>>>>some captures that are good. So I implemented a SEE function. The SEE returns >>>>>>the correct value on tests I have run. When I put this into my program so that >>>>>>if (attackervalue>DefenderValue)&&(SEE>=0) I keep the move as well, I got worse >>>>>>results on the WAC test suite. Before I put the see in I got 270/300 at 60 >>>>>>seconds per move and after I got 257/300 at 60 seconds per move. >>>>>> >>>>>>Is it just that there are no capture sequences in this test that need the extra >>>>>>captures, or is there something wrong with my SEE function? >>>>>> >>>>>>Thanks for any help, >>>>>> >>>>>> >>>>>>Landon W. Rabern >>>>> >>>>>It would be of help if you post some relevant positions. I may just guess now >>>>>that if you do check detection in qsearch you may find some mating combinations >>>>>with 'losing captures', when recapturing piece is overloaded simply, so in next >>>>>move capture is mate. (Or you may do some non-capturing,checking moves in >>>>>qsearch which complicates matters still). With SEE you miss those. Question is >>>>>if average speedup of SEE in non-tactical positions offsets those few missed by >>>>>using SEE.... >>>>> >>>>>-Andrew- >>>> >>>>I do not do checks in q-search. The problem is that I should be missing fewer >>>>tactical positions with SEE, than with just throwing all captures out where >>>>attackerValue>defenderValue. >>>> >>>>Landon >>> >>>So maybe you are much faster then SEE with throwing away all captures where >>>attackerValue>defenderValue... Single out those positions and compare PVs and >>>nodes produced with both versions of your qsearch ply by ply. Then maybe you/we >>>can learn what's going on. Do you reach extra ply or does your program find >>>those moves one/few plys sooner? >>> >>>-Andrew- >> >>I rememeber reaching an extra ply in many cases, I can not take a look at the >>PV's until late tonight since I am at work now and will be working late to get >>the product out on time. >> >>Landon > >I cannot imagine throwing A>D captures out of the qsearch works. Even if it >solves many testpositions, it cannot be accurate in games. Would you mind trying it out to see if you get similar results? I throw everything out where A>D except I keep all captures where the captureer is a king. > >Furhter I think you should compare SEE pruning with no pruning at all. And then >you should see that SEE goes deeper on average. Or else your SEE has a bug OR >your SEE is too slow. With SEE it does go deeper on average than with nothing. And my SEE function is very fast. > >Good way to debug your SEE is to compare the SEE result with the QSearch result. >If this doesn't work, make a new special qsearch, that simulates SEE behaviour. >It doesn't matter if it is slow, as long as it works accurate. Comparing the two >will show you if there are bugs. I set up a bunch of mock positions that had a bunch of capture/recapture and ran through them on paper and then with the SEE, same result, so I think it is correct. Last night I ran WAC with no pruning in the qsearch and I got 253/300 compared to with SEE 257/300 and with A>D plus king caps 270/300. The I ran on WCSAC and got 745/1002 with SEE and 752/1002 with A>D +king caps. If anybody has ever tried just cutting with A>D + king caps let me know. I know that it should be doing worse since it would leave a hung pawn that could be captured by a queen at the end of the search. Thanks, Landon
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.