Author: Bas Hamstra
Date: 05:15:17 07/20/00
Go up one level in this thread
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. 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. 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.
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.