Author: Ross Boyd
Date: 16:58:55 09/03/04
Go up one level in this thread
On September 03, 2004 at 10:25:27, Stuart Cracraft wrote:
>On September 03, 2004 at 06:41:16, Ross Boyd wrote:
>
>>On September 03, 2004 at 00:43:27, Stuart Cracraft wrote:
>>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.
No problems....
null_depth = remaining_depth - R; // R=2 for me, always
if( null_depth > ONE_PLY)
nullmove_score = -search(-beta, -beta+1, null_depth - ONE_PLY);
else
nullmove_score = -quiesce(-beta,-beta+1);
unmakenullmove();
if (nullmove_score >= beta) {
return nullmove_score; // Fail soft
}
if (nullmove_score == -CHECKMATE+ply+1) {
hashflags |= THREAT_FLAG; // Tag it as a position with mate threats
}
// and then this code, (more or less)
if (hashflags & THREAT_FLAG)
remaining_depth += EXTEND_THREAT;
Actually, since changing my search to count nullmoves as a ply increment, it
works better with -CHECKMATE+ply+2....
HTH,
Ross
>>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.