Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Algorithms for solving helpmates?

Author: Ian Osgood

Date: 14:11:56 01/10/00

Go up one level in this thread


Heiner,

First I would like to thank you for releasing the source to this excellent
problem solver!  Comments below:

On January 09, 2000 at 12:31:44, Heiner Marxen wrote:

>On January 07, 2000 at 21:22:36, Ian Osgood wrote:
>

...

>>Well, I did figure [out how to modify CHEST to solve the NxR Christmas helpmate] (I believe), but helpmates are not supported as nicely
>>as other types of problems (no specialized pruning).  Putting in performance
>>metrics, I found that it was searching 4x more slowly than the full-width
>>version of TSCP I had cobbled together.
>
>Yes, I would expect CHEST to be slower than a simple but fast searcher, here.
>Help mates are currently included just for fun (and for completeness).
>There are some vague ideas how to do helpmates really fast, but they
>are far from ready.
>
>For the NxR puzzle I have done a hack myself inside the formoves() loop
>in do_help_rest(), before and after the recursive call.  The latter
>is necessary to mask sub-solutions in zero moves.  Here is the relevant part:
>
>#if WITH_XMAS_99
>        if( plies <= 1 ) { /* Weihnachts-Raetsel: NxR# */
>            if( (bp->b_f[mp->m_from].f_f != springer)
>             || (bp->b_f[mp->m_to  ].f_f != turm)
>             || (bp->b_f[mp->m_to  ].f_c == empty) ) {
>                subres = ANARES(ANA_MANY&~1, FALSE);
>                goto have_subres;
>            }
>        }
>#endif
>        move_execute(bp, mp); APC_CINC(); scinc(mvx_def((plies+1)/2));
>        if( plies > 1 ) {
>            subres = do_help_full(bp, plies-1, (AnaOut*)0);
>        }else {                         /* plies==1: must be [stale]mate, now */
>            if( (!!in_check(bp)) == mustmate ) {
>                APC_CINC();
>                subres = ANARES(0, !move_gen(bp, (Movelist*)0));
>            }else {
>                subres = ANARES(0, FALSE);
>            }
>        }
>        move_undo(bp);                  /* move back */
>#if WITH_XMAS_99
>        if( (subres == ANARES(0,TRUE)) && (plies>1) ) {
>            if( (bp->b_f[mp->m_from].f_f != springer)
>             || (bp->b_f[mp->m_to  ].f_f != turm)
>             || (bp->b_f[mp->m_to  ].f_c == empty) ) {
>                subres = ANARES(ANA_MANY&~1, FALSE);
>                goto have_subres;
>            }
>        }
>#endif
>have_subres:;

Thanks for the code!

Yes, this is where I inserted my hack as well.  However, to avoid stopping
analysis on early mates, I replaced your second #if block above, with the
following code in do_ana():

    case JT_helpmate:						/* have full list */
#if WITH_XMAS_99
        result = ANARES(dep=ANA_MANY, FALSE);		/* ignore early solution */
#else
        if( in_check(bp) ) {					/* early solution */
            result = ANARES(dep=0, TRUE);
        } else {							/* mate */
            result = ANARES(dep=ANA_MANY, FALSE);
        }
#endif
        goto note_and_rdy;

Would you expect this to have the same effect?  I am not fully clear on how the
depth part of ANARES is used to prune the search.

Also, does ANARES(ANA_MANY&~1, FALSE) give the same result as ANARES(ANA_MANY,
FALSE) ?

>It was fast enough for me, to do the NxR puzzle completely on a fast machine,
>(500 Mhz, 350MB TT), thus verifying that the intended solution is unique.

To confirm correct usage: I need to solve the problem twice, once to look for
5.NxR++ and once to look for 5...NxR++?  The only difference is using the -x
flag  for the latter case, correct?  I'll also try a larger hash table (I was
using the 42M default).

>>(Oh, I found another bug reading FEN ('F') tags.  The inner while loop in
>>grok_fen() should read  while (*ip && !IS_SPACE(*ip)) {... )
>
>Rats!  You are right.  :-(

Isn't open source great?  People find your bugs for you, and your program
improves while you sleep!

>>I'm not sure I'd agree that it was well written (for maintainance, that is; it
>>seems pretty heavily performance tuned).
>
>Hmmmm, as author I disagree.  But I understand that you do not perceive
>it as being maintainance friendly.  The sources are the result of many
>years of experiments, some of them rather complex.  Also, performance
>is THE issue for CHEST, so that part should not come as a surprise.

Please excuse my comment.  It is difficult code to read compared to TSCP, but
that is by design.  Indeed, I was able to find the modification point within a
few hours of first browsing the code.  It is nicely put together and docmented
for such a mature and featureful program.

>>I'm still looking for public source for other search techniques, such as
>>proof-number search.
>>
>>IanO
>
>Heiner

Thank you for your reply!

Ian



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.