Author: Ross Boyd
Date: 03:41:16 09/03/04
Go up one level in this thread
On September 03, 2004 at 00:43:27, Stuart Cracraft wrote:
Cautionary note... I've had a few glasses of wine. (Hey! its Friday!)
>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.
>
>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
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...
After adding both the above TRACE improved noticeably OTB (and in test suites).
Hope this affirms your findings.
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.