Author: Stuart Cracraft
Date: 13:09:07 10/01/04
Go up one level in this thread
On October 01, 2004 at 14:41:48, Robert Hyatt wrote: >On October 01, 2004 at 12:21:51, Stuart Cracraft wrote: > >>On September 30, 2004 at 20:00:57, Robert Hyatt wrote: >> >>>On September 30, 2004 at 18:28:51, Stuart Cracraft wrote: >>> >>>>On September 30, 2004 at 18:04:05, Robert Hyatt wrote: >>>> >>>>>On September 30, 2004 at 14:25:34, Stuart Cracraft wrote: >>>>> >>>>>>On September 30, 2004 at 09:35:09, Robert Hyatt wrote: >>>>>> >>>>>>>On September 30, 2004 at 02:53:16, Stuart Cracraft wrote: >>>>>>> >>>>>>>>The null move killed, win-at-chess 141, has itself >>>>>>>>finally been killed, vanquished with the help of >>>>>>>>two board contributors whose combined suggestion >>>>>>>>led to a 17-fold reduction in time-to-solve. >>>>>>>> >>>>>>>>This posting announces those winners. First the >>>>>>>>stats! >>>>>>>> >>>>>>>>Now solved in 5.49 seconds on a P3 @ 1ghz it would be >>>>>>>>solved in under 2 seconds on more modern equipment. >>>>>>>>Formerly it took 95 seconds to solve. >>>>>>>> >>>>>>>>That's good enough for me. And it's good enough to win >>>>>>>>the $50 contest posed recently since it broke the >>>>>>>>10-second-and-under-barrieras posed in the contest >>>>>>>>posting. >>>>>>>> >>>>>>>>The search: >>>>>>>> >>>>>>>>Alpha=-1332 Beta=-531 Maxdepth=9999999 MaxTime=99999 >>>>>>>> 1/ 9 g2f1 0.00 -953 511 g2f1 f4d5 >>>>>>>> g2f1 f4d5 >>>>>>>> 2/ 9 g2f1 0.01 -953 884 >>>>>>>> g2f1 f4d5 c1g5 >>>>>>>> 3/12 g2f1 0.06 -953 11929 >>>>>>>> g2f1 f4d5 c1g5 d5f6 >>>>>>>> 4/16 g2f1 0.39 -953 72781 >>>>>>>> g2f1 f4d5 b3d5 c6d5 f1g2 d6e7 >>>>>>>> 5/24> g2f1 3.83 -552 978925 >>>>>>>> g2f1 b5b4 b3a4 f4d5 f6g5 d5e7 >>>>>>>> 5/25 c1f4 5.49 2260 1420038 c1f4 d6f4 h4h5 g6h5 h1h5 f4h6 h5h6 c7g3 g2g3 d7d >>>>>>>>6 >>>>>>>> c1f4 d6f4 h4h5 g6h5 h1h5 f4h6 h5h6 c7g3 g2g3 d7d >>>>>>>>6 >>>>>>>> 6/25 c1f4 6.06 2260 1519145 >>>>>>>> c1f4 d6f4 h4h5 g6h5 h1h5 f4h6 h5h6 c7g3 g2g3 d7d >>>>>>>>6 >>>>>>>> >>>>>>>>And with it the announcement -- because of the contribution >>>>>>>>of Will Singleton in indicating that null move should be >>>>>>>>avoided before leaves in the main search (and the sense >>>>>>>>of a comparison in an old commented out section of the >>>>>>>>code associated with disabled null move verification having been >>>>>>>>intended to do what Will suggested but having been miscoded >>>>>>>>by me and then #ifdefed out months ago) and Uri Blass' >>>>>>>>comments about my recaptures being too free and easy, >>>>>>>>the program went from a total of 95 seconds >>>>>>>>for wac 141 to 5.49 after these two suggestions were >>>>>>>>implemented. >>>>>>> >>>>>>>I doubt null-move is the problem. I do null-move _everywhere_ and Crafty has no >>>>>>>problem solving wac 141 doing so... >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>So Will and Uri are the winners, if they wish to accept, >>>>>>>>of the divided $50 prize. Because Will's contribution was >>>>>>>>more significant but less work for him and Uri's contribution >>>>>>>>was less significant but with more work for him, but in either >>>>>>>>case without the change from the other's suggestion the result >>>>>>>>would not have been as dramatic getting down to <= 10 seconds >>>>>>>>as stated in the earlier contest challenge a day or two ago, >>>>>>>>the award has been divided in half for the 2 winners. >>>>>>>> >>>>>>>>Will and Uri are welcome to send me, and only if they wish >>>>>>>>to collect, their postal mail addresses, to cracraft@cox.net >>>>>>>>and a check for $25 will be sent out to each. >>>>>>>> >>>>>>>>In the future, more contests will be held like this whenever >>>>>>>>I run into a huge roadblock but I see none looming presently, >>>>>>>>including a rather unusual one that I am not ready to announce. >>>>>>>> >>>>>>>>Thanks everybody for the help on 141 -- and thanks to Will >>>>>>>>Singleton and Uri Blass. >>>>>>>> >>>>>>>>Stuart >>>>>> >>>>>>What is your quiescence like? Do you investigate moves-that-check >>>>>>at the first ply of quiescence? >>>>> >>>>> >>>>>My q-search has _no_ checks or check-evasions whatsoever. Just captures, and >>>>>the captures have to appear to be at least equal using SEE or they get discarded >>>>>as well... >>>> >>>>What if a capture is a check or check evasion? Acceptable? >>>> >>>>Stuart >>> >>> >>>Yes, but Crafty doesn't notice this nor handle it differently as they are "just >>>captures" in the q-search... q-search doesn't detect mate stalemate or draw at >>>all either... >> >>How about check? I assume you don't hand off an incheck position to >>quiesce, saving the function call and keeping it investigated by >>the main search for one ply extension only at all places in the tree. > >That is why I extend on _giving_ check rather than on _escaping_ check. >Therefore I will _never_ drop into the q-search with the side on move in check, >unless I have extended so far that I don't extend the check a full ply... There >I just accept the errors since most likely a capture of the checking piece will >be the only valid move anyway... > > >> >>But in quiescence what if you end up in check? What then? > >I ignore it. If I can capture the checking piece, or if the king can capture >any piece to move out of check, it'll do so. Otherwise it will have to stand >pat... > > >> >>Stuart Based on this post I disabled my check-evasion extension in my quiescence and my main search and instead instituted in main search only an extension on checking move. Seemed to produce a lot fewer nodes, but in about the same time and only very slightly worse results on WAC (<1% worse). M My routine to determine whether incheck is expensive. I will play with this extension for a few days and see if any other twiddle can get it doing better given the overhead. 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.