[gnugo-devel] sente analysis

[kevin yong]

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 doesn’t 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 what’s the next-move and assess its
effects. For human player, it’s 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 it’s 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
it’s safe etc, then value it. What I m saying is gnugo
doing this entire process quite well for the
‘current-move’, but it’s 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