[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gnugo-devel] sente analysis
From: |
kevin yong |
Subject: |
[gnugo-devel] sente analysis |
Date: |
Sun, 20 Apr 2003 12:31:27 -0400 (EDT) |
Hi:
In general, to make gnugo strong, it needs increase
the depth of analysis. Specifically, for example, it
needs enhancement on the sente analysis of a move
(see regression cases 13x13:4, 13x13:83, 13x13:84,
endgame:201, golife:7 etc). Then, I give some thoughts
about how the sente analysis can be done. I feel that
it involves most steps of an entire move-generate
process. Take case 13x13:83 for example. B:L9 has been
considered but under valued, because gnugo doesnt see
the sente of the move. Somewhere if I insert a routine
call to push gnugo to think followup move AFTER L9, I
need to solve 2 basic issues: 1) how to raise the
candidate moves; 2) how to value each move. These
almost involve quite lots of gnugo gen_move procedure.
I either re-write the entire thing or try to call
existing gnugo routines. The answer maybe obvious:
call existing gnugo routines. However, in my
impression (maybe I m wrong), most of gnugo routines
are not ready to be called separately/indepedently. It
heavily depends on the global variables worm[],
dragon[], dragon2[], stack. Etc. Back to our example
case 13x13:83, AFTER we put B:L9 on stack, we want
gnugo to think whats the next-move and assess its
effects. For human player, its obvious, if W not
answer K10, B would move at K10. But the question now
is how can we make gnugo think next-move at K10 and
value it, then put this value as the followup value of
L9 (which should make B:L9 way more value than B:L12).
So, I have been looking around the source code to see
if somewhere I can call some routines of reading.c,
owl.c etc. but its little hard to find. To raise K10
as a candidate move, gnugo needs go through a long
process. Then need another long process to assess if
its safe etc, then value it. What I m saying is gnugo
doing this entire process quite well for the
current-move, but its hard to call its routines to
generate/value the next-move.
By the way, when we talked about regress case
endgame:603, we identify the issue is gnugo only look
at each local endgame separately, and we may need a
look ahead integrated end-game module. I give some
thoughts on that, I also realize without a solid sente
analysis, such a end-game module would not work as we
expected.
Any comments/suggestions are very welcome.
Kevin.
______________________________________________________________________
Post your free ad now! http://personals.yahoo.ca
- Re: [gnugo-devel] regress endgame:603, (continued)
- Re: [gnugo-devel] regress gunnar:8, kevin yong, 2003/04/11
- [gnugo-devel] regress lazarus:1, kevin yong, 2003/04/12
- Re: [gnugo-devel] regress lazarus:1, Evan Berggren Daniel, 2003/04/12
- Re: [gnugo-devel] regress lazarus:1, bump, 2003/04/13
- Re: [gnugo-devel] regress gunnar:8, kevin yong, 2003/04/13
- Re: [gnugo-devel] regress gunnar:8, Evan Berggren Daniel, 2003/04/13
- [gnugo-devel] sente analysis,
kevin yong <=
- Re: [gnugo-devel] sente analysis, Paul Pogonyshev, 2003/04/20