Author: Stuart Cracraft
Date: 07:25:27 09/03/04
Go up one level in this thread
On September 03, 2004 at 06:41:16, Ross Boyd wrote:
>On September 03, 2004 at 00:43:27, Stuart Cracraft wrote:
>
>
>Cautionary note... I've had a few glasses of wine. (Hey! its Friday!)
Good -- I hope it's Pinot Noir laced with resveratrol so that your
Sirtuin gene is activated.
>
>>So today I find out that my recapture is bad. It must be. Bob said so.
>>
>>I take 1 minute to reimplement it to be "extend on 2nd capture on the same
>>square in a row" because I heard someone else talking about that's the
>>way they do it and got a surprise a minute after that.
>
>In TRACE I found my tree explodes unless I limit capture extensions to the last
>3 ply of horizon depth && the pieces are of equal value eg NxN, BxB, BxN, NxB
>are all treated as equal captures.
Thanks I will play with this and other variants of recapture extension
to see what works best for me on WAC 141 and WAC in general.
>
>
>>
>>The result is that Qxf4 for Win-at-Chess comes into view
>>in 98 seconds and holds after having been missed after seemingly
>>endless runtime with the old bad recapture in or out. Of course
>>it is nothing like the 13,000 nodes that Tord (was it?) solves
>>141 in. Perhaps we should have a contest for who solves 141 in
>>the fewest moves. He would surely win. It takes me 24 million.
>>I admire a search that is so directed in so few nodes. Surely
>>we pay homage to Berliner with it, eh? Retire in peace in Florida
>>and then two category 4 storms hit. Unlucky fellow.
>>
>>Alpha=-1182 Beta=-682 Maxdepth=9999999 MaxTime=100000
>> 1/13 g2f1 0.01 -953 945 g2f1 f4d5
>> 2/13 g2f1 0.01 -953 1535 g2f1 f4d5 c1g5
>> 3/15 g2f1 0.02 -953 5010 g2f1 f4d5 c1g5 d5f6
>> 4/23 g2f1 0.09 -953 21387 g2f1 f4d5 b3d5 c6d5 c1c7 d6c7 f1g1
>> 5/25 g2f1 0.65 -953 179404 g2f1 b5b4 b3a4 f4d5 f6g5 d5e7
>> 6/44 g2f1 3.15 -953 728459 g2f1 b5b4 b3a4 f4d5 f6g5 d5e7
>> 7/48> g2f1 64.75 -703 15048349 g2f1 e8c8 f1g1 c8e8 c1b1 f4e2 g1g2 e2d4
>> 7/48 c1f4 98.86 5113 24322991 c1f4 e8e6 f4g5 d7e7 b3e6 e7e6 h1d1 d6e7
>> 8/48< c1f4 98.88 4863 24327933 c1f4 e8e6 f4g5 d7e7 b3e6 e7e6 h1d1 d6e7
>> 8/48 c1f4 108.60 4863 26455348 c1f4 e8e6 f4g5 d7e7 b3e6 e7e6 h1d1 d6e7
>> 9/48> c1f4 159.87 5113 38207334 c1f4 e8e6 f4g5 d7e7 b3e6 e7e6 h1d1 d6e7
>>
>
>TRACE solves this (now) in under a second on a PIII-450. Previously, it took
>several minutes...
>
>I can tell you that I debugged my THREAT extension code and found Crafty's exact
>method was not conducive to good results (for TRACE).
>I extend when nullmove_score==-MATE+ply+1
Please include the call to your search for the null move? I want to
see your window.
>
>This certainly helped to solve the position in about 20 seconds instead of
>several mins.
>
>When I added passive checking moves to the qsearch it brought that down to < 1
>sec. These passive checking moves are only generated/tried when all other good
>captures have failed low AND we are not in check...
>
Sounds interesting.
>After adding both the above TRACE improved noticeably OTB (and in test suites).
>
>Hope this affirms your findings.
Not as far along as you. Need to break out my bottle of Salmon Run Pinot
Noir.
>
>Now I must try Tord/Botvinnik/Markoff extensions to see if they help too.
>
>Best wishes,
>
>Ross *hic*
>
>
>>I know my PV is screwy and wonder why Bxf4 isn't played next. Anyone
>>know why? To me, Qxf4 followed by Bxf4 and then rook taking along the
>>H file looks like the natural PV. I wonder if that is another nasty
>>bug lurking. I am surprised there can be so many remaining considering
>>a fairly decent run-of-the-mill score on WAC 1-300. The set seems to
>>have shortcomings. Good for a first year's development effort though.
>>
>>I am not able to speed 141 up yet with Moreland's Mate Threat Null extension nor
>>Botvinnik-Markoff's extension, but hopefully those will help, though they
>>haven't so far. Nor did using checking moves in the quiescence search.
>>None of those three has improved the time of the above, for me. I haven't
>>tried leaving out all check evasion moves in the main search and quiescence
>>search which speeds up the program tons but makes tactical solution rates
>>suffer.
>>
>>New recapture tested just slightly less than 1% worse in score on Win-at-Chess
>>for me but is solid enough to be okay to keep as a permanent setting.
>>My recaptures happen at any level and there is no limit -- perhaps that
>>is not great. I should reread the archives and try to find Bob's earlier
>>recapture description.
>>
>>I see in Crafty 19.16 that he has this which I hadn't looked at,
>>having just heard someone else talking about capture to square
>>then capture to second square, but I didn't put in the material
>>score being restored so perhaps I got lucky or there's some
>>further speedup to be gained by the addition of the material
>>score requirement. (Btw, looking at Crafty, or GNU, or any
>>other better program, to me is a form of cheating. I don't
>>like doing it. I don't like the feeling I get after doing it,
>>and I refuse to do it more than very infrequently.)
>>
>>/*
>> ************************************************************
>> * *
>> * if two successive moves are capture / re-capture so *
>> * that the material score is restored, extend the search *
>> * by one ply on the re-capture since it is pretty much *
>> * forced and easy to analyze. *
>> * *
>> ************************************************************
>> */
>> recapture = 0;
>> if (!extended && Captured(tree->current_move[ply - 1]) &&
>> To(tree->current_move[ply - 1]) == To(tree->current_move[ply]) &&
>> (p_values[Captured(tree->current_move[ply - 1]) + 7] ==
>> p_values[Captured(tree->current_move[ply]) + 7] ||
>> Promote(tree->current_move[ply - 1])) && !lp_recapture) {
>> tree->recapture_extensions_done++;
>> extended += recap_depth;
>> recapture = 1;
>> }
>>
>>
>>Cheers,
>>
>>Stuart
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.