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