Author: Stuart Cracraft
Date: 07:20:38 09/03/04
Go up one level in this thread
On September 03, 2004 at 07:08:48, Andrew Platt wrote: >On September 03, 2004 at 00:43:27, Stuart Cracraft wrote: > >>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. >> >>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. > >Congrats but I seriously think there must be something strange if mate threat >extensions don't help. I don't have recapture extensions (yet) but the mate >threat brought it down from a 13 ply search to an 11 ply one. It's still way too My mate threat is broken. The null move before it is searching with a window of -beta+1,beta and Tord says he wouldn't do that. But I am wondering how wide a window to search with in null move prior to the mate threat extension. Comments anyone? >expensive because the tree is very large at that point and with the alpha-beta >window being wide open for the mate score it takes forever. > >Right now I'm focussing on why it doesn't get it sooner; after that I'll >implement re-capture extensions. > >I think that looking at checks in the quiescent search would have helped me a >little. When analyzing the trace files I see the null move dropping straight >into quiescent search with a mate (e.g. a null move after Qxf4 Bxf4 Rxh5 - null >- Rh8#). However, all it does is the stand pat evaluation which causes a beta >cutoff. The version of my program that solved 141 in a minute or two has: check-evade extensions in both quiescence and main search. In both cases, unlimited of each. Plus the recapture extension (two back to back captures on the same square), adaptive null move with varying R=2 or R=3, SEE to eliminate losing captures and SEE for Delta Pruning (Futility Cutoff) both in quiescence. I tried checking moves in the quiescence but that did not help. And as you know, my mate threat, botvinnik-markoff, etc. are not proven yet. I have a poor man's singular extension and that is too weird to even discuss. > >It would be too expensive for me to really deal with checks in qsearch because I >don't want to have to generate the legal capture modes. All I do is bomb out of >it if I see the King being captured. However, it might not be too expensive to >generate the legal moves at the first ply of qsearch if we're in check to catch >these conditions. I might try that and see if it causes testsuites to slow down >much. Why not detect if you are in check upon entry to quiescence and if so, just return the main search with depth=1? I do that and it really helps. Got the idea from a Ken Thompson applet. >Andy.
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.