Author: Landon Rabern
Date: 11:48:13 07/20/00
Go up one level in this thread
On July 20, 2000 at 14:35:56, Bas Hamstra wrote: >On July 20, 2000 at 12:24:49, Landon Rabern wrote: > >>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. > >I tried it. It did bad. It solves less positions and searches less deep on >average. I also compared with no pruning at all and SEE pruning. The latter two >solve an equal amount op positions and search equally deep. > > >SEE pruning: > >Positions: 300 >Right: 200 >Wrong: 100 >Right perc: 66.45 >Nodes: 4162440 >QNodes: 3877382 >Total: 8039822 >Average Depth: 5.29 > > >No pruning: > >Positions: 300 >Right: 201 >Wrong: 199 >Right perc: 66.78 >Nodes: 4166168 >QNodes: 10198475 >Total: 14364643 >Average Depth: 5.30 > > >Your A>D except for king pruning: > >Positions: 300 >Right: 198 >Wrong: 102 >Right perc: 65.78 >Nodes: 4162033 >QNodes: 3097453 >Total: 7259486 >Average Depth: 5.26 > >All three runned in the same (short) amount of time. Note that for this older >program of mine SEE pruning breaks even. It cuts a lot of nodes, but still >searches to the same depth. > >Your A>D pruning does slightly worse. But I think this "slightly" is misleading. >This system will kill you in real 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. >> >>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 Thanks, I think I know what the problem is now. You ran that at a very short time control, right? I ran at 60 seconds per move getting 9-14 plys deep, so I think I outsearched the main need for the q-search, I searched past the capture/recaptures in my main search and with the SEE it was just slowing this down a little causing me to miss more positions. I'll bet if I run it with no qsearch, I will get even better test results, but thats not good, so I will be switching to using SEE. Thanks again for trying that out, 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.