on the road to 3.8

With regard to bug #175, I have to agree that G5 on move 52
is
awkward, and that a more appropriate move would be B8 or F1.
However,
after viewing output with -t -t, it looks like gnugo is
choosing G5 to
increase territory, even though Chinese rules are being
used. Gnugo
should see the territories at B8 and F1 as needing to be
strengthened--which with the F1 territory, it does at
endgame (which
might actually be unnecessary.

I do admit though that I tested it under 3.7.10, not CVS. I
haven't
worked with CVS much, so could someone post the command I
need to use
to grab the source.

With bug #160, I have run into this too at times. One
possible (yet
not very good) options is to add a flag and (maybe) gtp
command for an
individual move time limit, like --time-limit X or
time_limit X, where
if gnugo reached that limit when trying to decide a move, it
would
simply choose one sort of at random.

Joseph Piche


_______________________________________________
gnugo-devel mailing list
gnugo-develgnu.org
htt
p://lists.gnu.org/mailman/listinfo/gnugo-devel

With regard to bug #120, I believe resigning is the correct
move for
gnugo, but I think more skilled players should confirm this.
When you
run gnugo with -t you see the output:

I pass.
... though, genmove() thinks the position is hopeless
You win by resignation.

This probably isn't a bug. When you analyze the board, you
see there
is no hope for B to connect his stones or get two eyes on
the board.

Joseph Piche


_______________________________________________
gnugo-devel mailing list
gnugo-develgnu.org
htt
p://lists.gnu.org/mailman/listinfo/gnugo-devel

Joseph Piche wrote:
> With regard to bug #175, I have to agree that G5 on
move 52 is
> awkward, and that a more appropriate move would be B8
or F1. However,
> after viewing output with -t -t, it looks like gnugo is
choosing G5 to
> increase territory, even though Chinese rules are being
used. Gnugo
> should see the territories at B8 and F1 as needing to
be
> strengthened--which with the F1 territory, it does at
endgame (which
> might actually be unnecessary.

F1 is safe and doesn't need defending, it's only
strengthened as part of 
the --capture-all-dead process. B8 on the other hand seems
necessary to 
avoid seki and that corner position should go into the seki
test suite, 
cf. e.g. seki:901-913.

> I do admit though that I tested it under 3.7.10, not
CVS. I haven't
> worked with CVS much, so could someone post the command
I need to use
> to grab the source.

For instructions, see https://sav
annah.gnu.org/cvs/?group=gnugo

> With bug #160, I have run into this too at times. One
possible (yet
> not very good) options is to add a flag and (maybe) gtp
command for an
> individual move time limit, like --time-limit X or
time_limit X, where
> if gnugo reached that limit when trying to decide a
move, it would
> simply choose one sort of at random.

This is much harder than it sounds. GNU Go just doesn't have
any 
infrastructure for aborting a search (or even the overall
move 
generation) based on time limits or other external factors.

/Gunnar


_______________________________________________
gnugo-devel mailing list
gnugo-develgnu.org
htt
p://lists.gnu.org/mailman/listinfo/gnugo-devel

Joseph Piche wrote:
> With regard to bug #120, I believe resigning is the
correct move for
> gnugo, but I think more skilled players should confirm
this. When you
> run gnugo with -t you see the output:
> 
> I pass.
> ... though, genmove() thinks the position is hopeless
> You win by resignation.
> 
> This probably isn't a bug. When you analyze the board,
you see there
> is no hope for B to connect his stones or get two eyes
on the board.

The resignation is a perfectly adequate response. The
question is why 
GNU Go didn't manage to live with a single stone. But I'm
not sure it's 
well spent time to try to locate where this particular game
collapsed, 
although H6 and H7 looks like possible candidates. Unless
someone makes 
an analysis sometime soon I'll just close this ticket as
wontfix.

/Gunnar


_______________________________________________
gnugo-devel mailing list
gnugo-develgnu.org
htt
p://lists.gnu.org/mailman/listinfo/gnugo-devel