Author: Stuart Cracraft
Date: 09:21:51 10/01/04
Go up one level in this thread
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. But in quiescence what if you end up in check? What then? 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.