Author: Heiner Marxen
Date: 15:43:41 01/10/00
Go up one level in this thread
On January 10, 2000 at 17:11:56, Ian Osgood wrote:
>Heiner,
>
>First I would like to thank you for releasing the source to this excellent
>problem solver! Comments below:
Thanks! :-) :-)
>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.
Hmmm, I'm quite sure, mine is correct (since I had to think about it
for some 10 minutes). Your modifications throws away ALL short solutions,
so this should also be correct, as long as we are sure that there really
is no short solution. So, yes, that should do it. Careful, I may err.
Verifying that there is no short solution (computing the shorter depths)
does not cost so much time. I did that (you probably too), so we can take
that for granted.
ANARES combines a success bit (solved/cannot solve) with a depth (normally
full moves). Asked to solve in N moves, the result may be succ-in-N,
fail-in-N, or succ-in-shorter, or fail-in-longer.
succ-in-N implies fail-in-M for all M<N.
>Also, does ANARES(ANA_MANY&~1, FALSE) give the same result as ANARES(ANA_MANY,
>FALSE) ?
No. Note, that the normal recursive calls count full moves, while the
special helpmate functions count in plies. That &~1 truncates down to even,
and should only appear in the helpmate part. Otherwise, both are nearly
identical.
>>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).
Yes, correct, you got it. Because the job is so large, I splitted it manually
into the subjobs, to be able to restart in the middle. Generally, using
-x is preferable.
Regarding hash table: do not exceed your available real memory! That would
slow down. You may also try option "-E 8", which does more hash table
probing in help mates (ETC). It seems to pay off, here.
>>>(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!
Yes, you are absolutely right! Now I smile :-) :-)
>>>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 am very pleased to read that. Your detailed comments above already made
clear that you did understand some relevant parts of the 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
You are welcome!
Heiner
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.