Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: WAC 141 blowup

Author: Stuart Cracraft

Date: 08:16:20 09/01/04

Go up one level in this thread


On September 01, 2004 at 04:31:48, Bas Hamstra wrote:

>This shows the fundamental blindness that nullmove can have for mates, if you do
>no checks in the qsearch. I know you are doing check-evasions, but with checks I
>mean generating check-giving moves in the qsearch (for example only the first
>ply).  Try it. In combination with the mate extension it will solve this one
>instantly.
>
>Bas.

Thanks Bas -- I will try this. Should be interesting... also to see
how it affects the search outside of this position.

>
>
>
>
>On September 01, 2004 at 00:51:47, Stuart Cracraft wrote:
>
>>I know this is a long shot throwing this out there without much more
>>info, but perhaps I'll get lucky and someone has seen this before.
>>It's appeared on this bulletin board about 6 years ago.
>>
>>[D]4r1k1/p1qr1p2/2pb1Bp1/1p5p/3P1n1R/1B3P2/PP3PK1/2Q4R w - - bm Qxf4; id
>>"WAC.141";
>>
>>This position is supposed to be a good test for the implementation
>>of Moreland's mate threat extension (if null move search value returns a mate,
>>extend, or if it returns a mate one move away, extend (the more limited version)
>>He says many humans can see this mate threat (even I could and I am a class
>>C or B player) along the h-file but that some null move type programs have a
>>problem, hence his extension.
>>
>>I am pretty sure my program is implementing the extension but it
>>grinds and grinds and can't break free from Kf1 to the winning Qxf4.
>>
>>with mate threat code:
>> 1/11  g2f1  0.00 -953      352 g2f1 f4d5
>> 2/11  g2f1  0.01 -953      723 g2f1 f4d5 c1g5
>> 3/16  g2f1  0.01 -953     2038 g2f1 f4d5 c1g5 d5f6
>> 4/16  g2f1  0.05 -953     9887 g2f1 f4d5 b3d5 c6d5 f1g2
>> 5/21  g2f1  0.36 -953    75432 g2f1 b5b4 b3a4 f4d5 f6g5 d5e7
>> 6/33  g2f1  1.32 -953   267360 g2f1 b5b4 b3a4 f4d5 f6g5 d5e7
>> 7/33  g2f1  9.36 -939  2144638 g2f1 a7a5 f6g5 f4e6 c1e3 d6e7 g5e7 d7e7
>> 8/34  g2f1 16.14 -939  3355663 g2f1 a7a5 f6g5 f4e6 h4e4 a5a4 b3e6 e8e6 f1g1
>>  9th ply here takes too long and didn't finish in a decent amount of time
>>
>>without mate threat code
>> 1/11  g2f1  0.00 -953      352 g2f1 f4d5
>> 2/11  g2f1  0.01 -953      723 g2f1 f4d5 c1g5
>> 3/16  g2f1  0.01 -953     2038 g2f1 f4d5 c1g5 d5f6
>> 4/16  g2f1  0.05 -953     9887 g2f1 f4d5 b3d5 c6d5 f1g2
>> 5/21  g2f1  0.36 -953    75432 g2f1 b5b4 b3a4 f4d5 f6g5 d5e7
>> 6/33  g2f1  1.39 -953   267360 g2f1 b5b4 b3a4 f4d5 f6g5 d5e7
>> 7/33  g2f1  8.16 -939  1875448 g2f1 a7a5 f6g5 f4e6 c1e3 d6e7 g5e7 d7e7
>> 8/34  g2f1 15.78 -939  3145843 g2f1 a7a5 f6g5 f4e6 h4e4 a5a4 b3e6 e8e6 f1g1
>> 9/42  g2f1 151.08 -825 30769486 g2f1 g8f8 h4h5 g6h5 h1h5 e8e1 f1e1 d6b4 e1d1 f4
>>h5 c1h6 f8e8
>>10/46  g2f1 471.92 -825 92873175 g2f1 e8b8 h1g1 f4e6 h4h5
>>11/46> g2f1 666.85 -575 133140320 g2f1 e8b8 h1g1 f4e6 h4h5
>>
>>basically blows up at ply 9 and moves on to ply 10.
>>ply 11 then gets a fail high. I decided not to wait for
>>the final ply 11 search as it was taking too long with the wider window.
>>
>>The mate threat code comes right after the null move portion in the main search
>>and is:
>>
>>#ifdef MATETHREAT
>>  // If no extension so far, and null move thinks we're mated next move
>>  // then extend. Sorry, I don't use fractional extensions presently.
>>  if (!extend && value == -MATE+qdepth+2) {
>>//    printf("mate threat:\n");pbd(bd);getchar();
>>    extend=1;
>>    depth++;
>>  }
>>#endif
>>
>>I've tried it with the comment uncommented and it does show positions
>>with the rook threat along the h file with the long-diagonal bishop's
>>support threatening mate so I know it is seeing the threat, clearly.
>>
>>In this code, qdepth is like ply in most programs. It is poorly named
>>and will be renamed at some point.
>>
>>Program structure if that helps for the above:
>>
>>  Principal Variation Search
>>  Adaptive Null Move
>>  Move ordering by hash move, captures (mvv/lva), history heuristic, centrality
>>  Quiescence extends all checks with 1-ply search handoff by Main-search
>>  Quiescence uses SEE to avoid all SEE-negative captures
>>  Quiescence uses delta (futility) pruning with margin of maximum positional
>>    score so far for side to move
>>  Main search extends all checks by one, does one-move reply extension
>>  (There are other things like Enhanced Transposition Cutoff, Internal
>>   Iterative Deepening, Pawn Promotion and threat-to-promote extensions,
>>   recapture extensions, MTD(f), etc. that are disabled since they didn't seem
>>   to help with my one-second searches.)
>>  Hashing is done only in main search and algorithm is replace always
>>    when length >= depth stored in table. Hash table is single-tier only.
>>  Evaluation is material-only with pc/sq presently. (Next year is full eval.)
>>  Evaluation is in millipawns. Typical maximum positional score is 150. Pawn
>>   is 1000
>>
>>Goal for this year was to simply get rid of bugs in the non-evaluation
>>areas of the program, particularly the search.
>>
>>Thanks ahead,
>>
>>Stuart
>>
>>P.S. The program is solving 241/300 on WAC on the same slow 1ghz p3 and at
>>the same 1 second per position setting that Crafty 19.16 gets 270/300 on --
>>fun since only was 175/300 a couple months ago and the program is less than 5
>>months old. Also recently up from expert score on IQ4 to master. Did not code
>>specifically for any given position other than one in WAC (141 is the second.)
>>I did not look at the positions beyond the first couple and avoided looking at
>>the printout except the summary/stats. Position printout was disabled, etc.,
>>etc.



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.