Author: Will Singleton
Date: 17:34:25 01/30/01
Go up one level in this thread
On January 30, 2001 at 09:41:46, Robert Hyatt wrote: >On January 29, 2001 at 19:10:44, Will Singleton wrote: > >>On January 26, 2001 at 09:41:51, Robert Hyatt wrote: >> >>>On January 26, 2001 at 01:16:37, Will Singleton wrote: >>> >>>>On January 26, 2001 at 00:06:31, Robert Hyatt wrote: >>>> >>>>>On January 25, 2001 at 23:49:07, Robert Hyatt wrote: >>>>> >>>>>>On January 25, 2001 at 21:35:10, Will Singleton wrote: >>>>>> >>>>>>>On January 25, 2001 at 09:41:41, Robert Hyatt wrote: >>>>>>> >>>>>>>>On January 25, 2001 at 00:16:04, Andrew Dados wrote: >>>>>>>> >>>>>>>>>Thanks Bob for very interesting report. >>>>>>>>>A couple of loose thoughts... >>>>>>>>> >>>>>>>>>Recapture extension is intuitively no good for tactical suite for a simple >>>>>>>>>reason: all tactical lines give up temporarily material. And lines with >>>>>>>>>exchanging down pieces are not 'beautiful' for humans - which was probably one >>>>>>>>>of conditions for selecting a 'tactical' position into set like WAC. >>>>>>>>> >>>>>>>>>It is hard to say if your program plays weaker or stronger in practical games >>>>>>>>>because of it. And, btw, one of Craftys strengths is exchanging down to won >>>>>>>>>endgame. Maybe some sort of nunn-type match between 2 versions can give more >>>>>>>>>data about it? >>>>>>>>> >>>>>>>>>And if you come down to think about the trend - It would be interesting to run >>>>>>>>>your test with recapture extension going below zero....:) >>>>>>>>> >>>>>>>>>-Andrew- >>>>>>>> >>>>>>>>Ken Thompson got me started on this in the early 80's. The idea is that >>>>>>>>if you are in some kind of trouble (say losing a pawn) then one way to help >>>>>>>>"hide" this is the good old BxN PxB sequence. BxN forced the opponent to >>>>>>>>recapture the bishop, and that eats two plies of your total search, maybe >>>>>>>>hiding the pawn loss. Extending a ply partially offsets this... >>>>>>>> >>>>>>>>But I have never tested it very thoroughly. I am going to turn it off on >>>>>>>>one version and play an extended match, 2cpus to 2cpus.. I'll report on the >>>>>>>>result later.. >>>>>>> >>>>>>>I predict the capture extension version will win easily, especially in medium >>>>>>>blitz games (5 0). I have done that test (but not the wac test), and my program >>>>>>>definitely plays better with a limited capture extension. >>>>>> >>>>>> >>>>>>I have run 3 100 game matches so far. In the first, the recapture extension >>>>>>won by a small margin. IN the second, it lost by a big margin. In the third.. >>>>>>can't report yet... 3 more games to go... >>>>>> >>>>>>I am playing fairly fast blitz games which is where I generally see the best >>>>>>results for extensions... >>>>>> >>>>>>More data in a bit... >>>>> >>>>>\ >>>>> >>>>>300 games... 3 sets of 100 games played at 40 moves in 1 minute, each >>>>>program getting 2 cpus, ponder=on, etc... >>>>> >>>>>match 1. recap wins 26-18 with rest draws. >>>>>match 2, recap loses 3-20 with rest draws. >>>>>match 3, recap loses 6-21 with rest draws. >>>>> >>>>>games were played with learning=off, without a books.bin/bookc.bin to get a >>>>>bit of variety... >>>> >>>>Don't know what to say about that, except that I will run my test again, games >>>>to be played on ICC, 5 2, squirtle v squirtx (recap v no_recap). My test >>>>versions use the same books, but have a random value which selects the opening, >>>>and also changes the book depth. >>>> >>>>Intuitively, and also taking into account the countless articles and many >>>>programs which adhere to the recapture extension idea, I cannot help but be >>>>surprised at and question your results. But, as I say, I will report back. >>>> >>>>Will >>> >>> >>>No more surprised than I was when I first saw the WAC data either. However, >>>I have had lots of cases over the years where something worked for someone >>>else but not me, and vice versa. If you look at main.c in crafty you will >>>find places where something failed for me at one point, but a year later it >>>worked fine after extensions or something was changed somewhere else... >> >> >>Ok, I did some testing, and found that my recapture extension doesn't seem to >>have much effect. I guess I don't understand why that would be the case, but >>there it is. In most positions, it seems as if you'd be losing a ply if you >>didn't extend those critical lines. >> >>In the WAC test, the recapture version solves 2 more than the non-recap. But in >>head-to-head play (icc blitz), the recapture version lost 52-56 in a 150 game >>match. All in all, there appears to be very little difference. >> >>I'll probably take it out. >> >>Will > > >I played hell testing this, unknowingly. But the data turned out to be >useful. I played (I thought) one 100 game match. However, I played 100 >games with the winboard match mode option, but I had it in a loop. AFter >I found it still running a couple of days later, I looked at the totals >and the non-recapture version won by a very significant number. I have >disabled it and now require -DRECAPTURE to compile it back in for someone >that wants to play with it. > >I am not sure this is as significant when playing other programs however. As >I have said before, playing yourself with 1 minor difference in the two versions >tends to exaggerate the difference. > >However it was (and is) a surprise. One good test case is the kopec suite, >position 22, where Bxe4 is the key. With recap I see it at 6, without I see >it at 8. But the difference in time is like .5 seconds for 6 vs 3 seconds for >8 (3 seconds due to things being faster without the recap extension). > >This is a very good example of "test, test, test, rather than taking everybody >elses word that it is a good idea. > >Next suspect is my push passed pawns extension... I have heard that a couple other guys can demonstrate better results using recap, and that it might have something to do with futility pruning. How I don't know. BTW, I looked at the altivec instruction set, and it has the permute and merge instructions you referred to. And even though it's a short vector, it's long enough so that one could probably write some fast board-scanning routines. For example, permuting a slider's ray into a register should allow for quickly finding occupied squares (mobility, in-check, etc). Some redesign involved, but worth a try.
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.