gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] regress gunnar:8


From: Evan Berggren Daniel
Subject: Re: [gnugo-devel] regress gunnar:8
Date: Sun, 13 Apr 2003 13:23:18 -0400 (EDT)

This is really of very limited usefulness to me.  I can go investigate
gunnar:17 now, but you haven't really given me anything to work with that
I wouldn't have found out immediately on my own.

The comment with the testcase provides a good starting point:
 # T6 allows a combination attack. Necessary to fall back.

From this, it seems likely that something is going wrong in the
atari_atari safety confirmation.  In fact, there's no need to look at why
the moves were proposed at all, or how they got the values they did; if T6
were safe, which GNU Go believes it is, then it would be the correct play.
If GNU Go were to understand that it is not safe, it would probably find
S8.

Evan Daniel

On Sun, 13 Apr 2003, kevin yong wrote:

> Hi, Evan:
>
>   i had a quick look at regress case gunnar:17.
>
>   Problem: T6 wrong, S7 right.
>
>   I went through log file and source code, and found:
>
> It seems that: at ussual analysis (after
> exam_positions and move_reasons) process, it dismissed
> T6 and choose S8 (better S7? That?s another story).
>
>   Top moves:
>   1. S8  3.91
>   .. .. ..
>   Checking safety of a white move at S8
>   Move generation likes S8 with value 3.91
>
> But gnugo went on and T6 was raised again at  endgame
> analysis stage:
>
> Endgame pattern matcher is looking for move reasons
> for white!
> pattern 'EE302'+3 matched at T6
> zzz: add_move_reason, T6 PASS 20
> ...expands territory
> ...(min) territorial value 2.00
> ...reverse followup value 5.00
>   T6: 9.90 - change in territory
>   T6:   0.00 - total followup value, added 0.00 as
> territorial followup
>   T6: 2.50 - added due to followup (0.00) and reverse
> followup values (5.00)
>   T6:   12.40 0.00 - minimum accepted value
> Move generation values T6 to 12.40
> .. .. ..
>
> I think there are 2 issues here:
> 1. endgame pattern match found T6 by pattern EE302, is
> it right or wrong? I m not sure;
> 2. Then it directly go to review_move_reason() process
> without a examming/reading process, and got a high
> value and been choosen. Should moves found by endgame
> pattern match also go through a more detailed
> exam/reading process? I m not sure.
>
> >From genmove.c:
>
>   /* If the move value is 6 or lower, we look for
> endgame patterns too. */
>   if (val <= 6.0 && !disable_endgame_patterns &&
> !limit_search) {
>     endgame_shapes(color);
>     endgame(color);
>     gg_assert(stackp == 0);
>     if (review_move_reasons(move, &val, color,
> pure_threat_value, score,
>                           allowed_moves))
>       TRACE("Move generation likes %1m with value
> %f\n", *move, val);
>     gg_assert(stackp == 0);
>     time_report(1, "endgame", NO_MOVE, 1.0);
>   }
>
> In summary, I found some info about the problem, but I
> cant exactly pinpoint the problem and solution. So, I
> pass these info for you reference. Like to hear your
> comments.
>
> Kevin.
>
>
>
>
>
> ______________________________________________________________________
> Post your free ad now! http://personals.yahoo.ca
>
>
> _______________________________________________
> gnugo-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnugo-devel
>
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]